> On Feb 10, 2017, at 10:08 AM, Abe Schneider <[email protected]> wrote:
>
>>
>> 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.
>
> That's a fair point, though I think Java's type erasure in generics
> surprises/confuses a lot of people (and takes away a lot of the
> potential power of generics).
I consider Java’s type erasure to be orthogonal to the
overloading/customization point issue, but of course I agree that it’s
surprising.
> I can see the advantage of protocols if they allowed this type of design:
>
> protocol LinearOperations {
> associatedtype StorageType
> static func dot(_ lhs:Tensor<StorageType>, _
> rhs:Tensor<StorageType>) -> Tensor<StorageType>
> ...
> }
>
> extension Tensor: LinearOperations {
> ...
> }
>
> extension Tensor: LinearOperations where StorageType:CBlasStorage<Float> {
> ...
> }
>
> The advantage of this design is that the available functions are
> clearly defined, but it still allows new operations to be defined
> without having to touch the main code base.
I’m assuming that both of these extensions implement the static func dot(_:_:).
This is more interesting direction for me, because it’s taking the existing
notion of customization points via protocol requirements and extending that to
also support some level of customization.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
