My experience won’t be helpful to get you past these bugs, but simply for the record: when this feature was introduced I immediately implemented something that would have been very desirable in my codebase, more or less:
with(Optional<a>, Optional<b>, Optional<c>, ...) { a, b, c, ... in
closure executed only if all Optionals a, b, c wrap an actual value, and arguments to the closure are said value
}
It’s just pseudo-code but you can imagine variations on this theme that might be useful in other contexts (take a list of optionals, execute the closure with the first non-optional value bound as the only argument, etc.). There are obviously other ways to look at/solve this, but since Swift is both obsessed and stimulates obsession into syntactic sugar, this is the road I wanted to take.
Got very excited to see it working but then noticed compilation had become incredibly slow and unpredictable. Far from having the time or desire to dig into compiler sources to understand why this was happening, and whether there was a solution, or it required filing bugs, etc. I simply gave up. This is a story that repeats itself quite often with Swift. The first time you have to rely on -warn-long-function-bodies -warn-long-expression-type-checking to get past a nasty situation, you realize no-one is paying you for this, and maybe rather than getting excited about new language features you have to exercise self-restraint and focus on what creates value. There is a delicate balance between “this feature will make me more productive and hence help deliver sellable features” and “this feature will waste me a week just because I wanted the code to look prettier”. I don’t think it’s normal or desirable for a language to induce its users to think like this so often.
No matter what new feature you come across and get burned from, the game becomes one of searching periodically (mostly these forums) whether the problem you ran into has a solution yet. You are relying on “volunteers”, heroes in my book, with time on their hands to do the dirty work of documenting and filing problems. It feels wrong. It’s one more task that shouldn’t really be part of a developer’s schedule. When Macros were first introduced, early adopters noticed a huge compilation penalty, which was explained and discussed ad nauseam. Is the problem solved now? Macros would be a killer feature for my project, but the more cynical and productive part of me has learned to live without it.
Some on these forums are brilliant enough to understand Swift compiler internals and have time left over to turn that knowledge into better, faster “output” that turns into profit. I, of a lesser breed, see a huge and very different problem. Whether you’re trying to figure out parameter packs or just about any other language feature with its own baggage of problems, you butt against the bureaucracy in charge of all this, a group of exceedingly smart PL enthusiasts that doesn’t seem to understand the huge externalized costs it constantly puts on the developer community. It appears to thrive because enough brilliant people outside this bureaucracy are paying whatever price it takes to test these features and maybe help bring them to a usable state within a couple years (your post suggests the alternative outcome, i.e. a feature left unattended). Under these incentives, the system mostly captures feedback that validates the original goals. You won’t capture any feedback from those who don’t buy into their new role as “unpaid language and framework designer and tester for Apple, Inc.”
Looking at Swift and Apple frameworks I see the cost curve of understanding and using native everything going up and up and up. My best guess is that fewer teams are able to justify or crucially, enjoy, any of this. The unwanted side effect will be to see less, not more, software based on native languages and frameworks rather than vilified web-based equivalents.
These are just opinions of course. Apologies for the long post, I wish nothing but success for Apple’s platforms and all of us here.
