[swift-evolution] Compile-time generic specialization
dgregor at apple.com
Fri Feb 10 11:30:58 CST 2017
> On Feb 10, 2017, at 8:41 AM, Abe Schneider <abe.schneider at gmail.com> wrote:
> Hi Douglas,
>> 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).
Other languages in the C family (e.g., C#, Java) that have both generics and ad hoc overloading provide the same static-resolution behavior that Swift does, so someone coming from a language in the general “C” family will be confounded whatever we choose. Personally, I think C++ got this wrong—I feel that generic algorithm customization points and algorithm specializations should be explicitly stated, because it makes it easier to reason about the generic code if you know where those points are. Swift uses protocol requirements for customization points, but hasn’t tackled algorithm specialization yet.
More information about the swift-evolution