Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
slavapestov
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
32 ms
·
301.
▲
by
slavapestov
10y ago
No, it's valid advice. Non-WMO starts a frontend job for each file, WMO runs one job. The frontend jobs do not share state, so each one parses all the files in the module. In general the parser is very fast, and the type checker tries
302.
▲
by
slavapestov
10y ago
SourceKit itself is fairly stable. However it embeds a copy of the Swift type checker. :-)
303.
▲
by
slavapestov
10y ago
Most of the new warnings in 3.1 were with things that never should have worked in the first place (some stuff with public declarations referencing private typealiases in their type signatures and things like that). There were also some new
304.
▲
by
slavapestov
10y ago
You can download a 3.1 development snapshot. I'm not involved in preparing the official releases but I'm assuming the Linux 3.1 release will be very close to what is in swift-3.1-branch now. And all the action these days is on the
305.
▲
by
slavapestov
10y ago
I think there were differences around calling .description versus .debugDescription when a type is converted to a String, which had some odd behavior with Optional. I think there was an evolution thread about this but you'll have to Go
306.
▲
by
slavapestov
10y ago
Also have you tried enabling precompiled bridging headers? This was added in 3.1 with the goal of speeding up mixed Swift/ObjC builds (by none other than Graydon Hoare), but other than that I don't know much about it.
307.
▲
by
slavapestov
10y ago
With 'drop' passing a throwing predicate feels a bit esoteric, but consider something like 'map'. Suppose you are mapping over an array of file names and loading each one, which can throw. You would expect the 'map&
308.
▲
by
slavapestov
10y ago
There are two main sources of slow compile times in Swift -- the expression type checker has exponential in the presence of large numbers of overloads (which unfortunately includes arithmetic expressions and collection literals). The second
309.
▲
by
slavapestov
10y ago
Unit testing a compiler for a language like Swift is hard because there are so many features that interact in complex ways. There are unit tests but it's easy to miss things that look "obvious" in hindsight. Until recently th
310.
▲
by
slavapestov
10y ago
Your snippet works in the latest master development snapshot too it seems.
311.
▲
by
slavapestov
10y ago
Here's a funny story. At one point bcache development was funded by a startup (which I won't name here). They were using it as the local storage layer of a distributed storage product. I worked there for a year in 2014. Apparently
312.
▲
by
slavapestov
10y ago
You can find SourceKit crash logs in Console.app; can you file a bug and attach some of them?
313.
▲
by
slavapestov
10y ago
SourceKit crashes are caused by bugs in the Swift type checker most of the time; it's not SourceKit itself that's at fault usually. We did a lot of work to fix architectural problems in 3.1, especially with generics, and there wil
314.
▲
by
slavapestov
10y ago
> If I work at a company like Google I presumably have enough money to buy all the computing power I should need, so performance of the code isn't as important as developer time. Google and other big cloud shops care a lot about ene
315.
▲
by
slavapestov
10y ago
Every compiler supporting separate compilation has an ABI -- the question is whether the ABI changes between releases or not.
316.
▲
by
slavapestov
10y ago
Yeah. Nothing has really come close to offering the same experience as HyperCard in my opinion. The key feature that no subsequent environment has really been able to copy is that there's no distinction between "running" and
317.
▲
by
slavapestov
10y ago
> I think that would be the eventual goal, Objective-C minus C. I still think that if your goal was this gradually typed language on top of a dynamic runtime, it would make more sense to start anew and model your language after, say, Str
318.
▲
by
slavapestov
10y ago
> Objective-C could have been evolved into the language they wanted. Swift is memory safe -- I'm not sure how one could evolve Objective-C into that, without breaking compatibility with the C subset.
319.
▲
by
slavapestov
10y ago
> I don't consider 'BAD_EXEC' to be a descriptive error at all. Those are bugs, please report them: https://bugs.swift.org
320.
▲
by
slavapestov
10y ago
The Android port is maintained by a volunteer, Brian Gesiak. You can ask him about it on Twitter: https://twitter.com/modocache
321.
▲
by
slavapestov
10y ago
Swift 4 has a -swift-version flag. When set to 3, all valid Swift 3 code should compile.
322.
▲
by
slavapestov
10y ago
There were some improvements to type inference with closures in 3.1. Do you have example snippets that are giving you trouble?
323.
▲
by
slavapestov
10y ago
We fixed a lot of bugs while working on the new generics features in Swift 3.1 (and also recursive protocol constraints, which didn't quite make it in but a lot of the plumbing was done for it). For example, in practicalswift's fu