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@swift.org> wrote: > > On May 25, 2016, at 6:17 PM, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
