[swift-evolution] Compile-time generic specialization

[Douglas Gregor]

> On Feb 10, 2017, at 10:08 AM, Abe Schneider <abe.schneider at gmail.com> 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