[swift-evolution] [Pitch] Allow explicit specialization of generic functions

[Austin Zheng]

I would like explicit specialization as well.

For historical interest, there is a blurb in the generics design document describing the original rationale (https://github.com/apple/swift/blob/master/docs/Generics.rst <https://github.com/apple/swift/blob/master/docs/Generics.rst>, "Type Parameter Deduction").

Austin

> On May 25, 2016, at 8:39 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On May 25, 2016, at 6:17 PM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello,
>> 
>> This is a new pitch to allow explicitly specializing generic functions. Notice that potential ambiguity with initialisers and how I’m currently trying to avoid it. Please let me know what you think!
> 
> +1111!1eleventyone!
> 
> I’ve always wondered why that was disallowed in the first place… In any case, it’ll make it easier to work with functions in which the generic parameter only appears in the return signature. The current workaround is to pass in a “dummy” variable like so:
> func foo <T> (_: T.Type) -> T {}
> let x = foo(Int.self)
> or to use explicit type annotation:
> func foo <T> () -> T {}
> let y: Int = foo()
> 
> The first is annoying (although less so in Swift 3 since we won’t need the `.self` part anymore), the second requires creating a new variable which makes the code jarring, and the two are incompatible with each other since the signatures are different.
> 
> Also, I’d think it’d simplify the compiler, since there’d be one less error condition.
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/f7c02a22/attachment.html>