[swift-evolution] Compile-time generic specialization
abe.schneider at gmail.com
Fri Feb 10 10:41:59 CST 2017
> I don't think it's a particularly good time in Swift's evolution to
> introduce such a feature. Swift 4 actually has a pile of Generics
> improvements already, and relative to those, this kind of specialization is
> a bit of a niche feature. That said, it's not totally afield---the
> conditional conformances proposal talks about a similar issue in the context
> of existing dynamic dispatch (protocol requirements), and we're not quite
> sure how big of an issue it will be.
Okay, that's fair. My main goal was to at least raise the issue and
hope that at least some day it may get added to the roadmap. More
immediately, if some of the changes being discussed are made to how
protocols/extensions work, I think that could a potential solution.
Also, since I don't want to come off as sounding like I'm just
complaining, thank you everyone who have put so much effort and
thought into Swift! It's quickly made it's way into one of my favorite
> Swift's generics system is quite drastically different from C++ templates,
> so I (personally) am not strongly motivated by the first argument: there's a
> big leap to make going from C++ to Swift, particularly if you know C++
> templates well, and this seems a small part of that. The second argument I
> agree with---it does come up from time to time.
I wouldn't expect Swift's generics to work exactly the same as C++.
However, I have seen discussion come up in discussion that Swift
should cause the least amount of surprises for people coming from a
C-based language. Thus, for people coming from C++, this will cause a
lot of surprise -- especially since it does the correct behavior when
being called from a non-generic function. I hadn't noticed the
difference in behavior until much later in development of my library
(which is now causing a lot of refactoring to occur).
More information about the swift-evolution