> On Feb 10, 2017, at 8:41 AM, Abe Schneider <[email protected]> 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.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
