I guess this means in large application you should always annotate your types. It should be enforced with a linter.
Not at all. Most code doesn't suffer from this problem. It's a pathological case.
Go Home Swift Compiler, You’re Drunk
11–20 of 29 posts
Re: Go Home Swift Compiler, You’re Drunk
#12How many other two year old languages are there in large scale use? It's not surprising there are issues in compiling things. I've used so many languages early on since I started in the 80's and you can always find some syntax the compiler doesn't like. Given the pedigree of the people building Swift who also built the entire llvm system it's pretty good for something still in diapers. Now take XCode, that is some re…
Swift development began in 2010.
Re: Go Home Swift Compiler, You’re Drunk
#13(FWIW, I just pushed a fix for this bug.)
EDIT: To be clear, addressing these kinds of issues is something we've been aggressively pursuing for Swift 3, and will continue to do so.
Re: Go Home Swift Compiler, You’re Drunk
#14I recently wrote a tool to report Swift block compile times, since this kind of thing can be unpredictable. At Hipmunk we run it every night to find out how we can make our builds faster.
Another common culprit of slow compile times is usage of lazy var.
Re: Go Home Swift Compiler, You’re Drunk
#15I recently wrote a tool to report Swift block compile times, since this kind of thing can be unpredictable. At Hipmunk we run it every night to find out how we can make our builds faster. Another common culprit of slow compile times is usage of lazy var. https://github.com/irskep/swift_compile_times_parser
Thanks, Steve! I'm well aware of the type checker's problems with 'lazy', and it's something I hope to address soon.
Re: Go Home Swift Compiler, You’re Drunk
#16I recently wrote a tool to report Swift block compile times, since this kind of thing can be unpredictable. At Hipmunk we run it every night to find out how we can make our builds faster. Another common culprit of slow compile times is usage of lazy var. https://github.com/irskep/swift_compile_times_parser
Thanks, Steve! I'm well aware of the type checker's problems with 'lazy', and it's something I hope to address soon.
While you're here, I should say: first, thanks for your work, and second, it would be nice if the compiler could log the timing data in a consolidated form so my script wouldn't be necessary. :-) Regex-parsing and aggregating a bunch of log lines seems dicey.
Re: Go Home Swift Compiler, You’re Drunk
#17(FWIW, I just pushed a fix for this bug.) EDIT: To be clear, addressing these kinds of issues is something we've been aggressively pursuing for Swift 3, and will continue to do so.
Nice commit message:
https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd54...
Re: Go Home Swift Compiler, You’re Drunk
#18Earlier quoted context omitted.
Thanks, Steve! I'm well aware of the type checker's problems with 'lazy', and it's something I hope to address soon.
While you're here, I should say: first, thanks for your work, and second, it would be nice if the compiler could log the timing data in a consolidated form so my script wouldn't be necessary. :-) Regex-parsing and aggregating a bunch of log lines seems dicey.
Unfortunately, debug-time-function-bodies isn't an "officially" supported flag, so improving it isn't a high priority right now.
...That said, we'd be more than happy to take improvement PRs in this area, if you're feeling up for it!
Re: Go Home Swift Compiler, You’re Drunk
#19I guess this means in large application you should always annotate your types. It should be enforced with a linter.
I've been using Swift for a couple of months now. While I appreciate that type inference makes for more concise and cleaner code, it also impedes code comprehension. The absence of explicit types forces me, reading an unfamiliar piece of code, to work harder to figure out the type of each expression. This is especially true for expressions of type Optional.
(But at least each expression has a type. While I love Python and have used it for many years, I don't like the uncertainty about types.)
Re: Go Home Swift Compiler, You’re Drunk
#20I guess this means in large application you should always annotate your types. It should be enforced with a linter.
Not at all. Most code doesn't suffer from this problem. It's a pathological case.
The code that triggered this long type inference loop seems pretty normal. It's not like Damas-Milner's pathological case (deeply nested instantiations of type schemas), which is genuinely uncommon.