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

[Mark Lacey]

> On May 25, 2016, at 11:37 PM, David Hart <david at hartbit.com> wrote:
> 
> The former. This proposal is simply to make certain scenarios which require to be explicit to be more elegant and more in line with generic types.
> 
> Moreover, what you suggest might be dangerous. Imagine this code:
> 
> func foo<T, U>() -> (T, U) { ... }
> let a = foo<Int, Foobarr>()
> 
> I just did a typo on Foobarr and Foobarr does not exist. So the compiler has to guess that I meant an inferred generic type, which might not be what I want. And I don't think that the compiler should require us to remember the actual name of the generic types.

I probably wasn’t clear enough here, but what I meant was something like:
  func foo<T, U>(x: U) -> (T, U) { … }

  let a = foo<Int, ...>(v)   // the second type was unspecified, but can be inferred by the argument ‘v'

Ignore the specific syntax for the unspecified type here. Would your expectation be that something like this work as well, or does one need to specify all-or-none when it comes to the type parameters?

If the former, what is the proposed syntax for what goes in the positions of the types that are unspecified?

Mark

> 
> On 26 May 2016, at 03:38, Mark Lacey <mark.lacey at apple.com <mailto:mark.lacey at apple.com>> wrote:
> 
>> 
>>> On May 25, 2016, at 4: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!
>> 
>> Hi David,
>> 
>> I’m wondering if the only motivation here is to be more explicit about the types involved so you can avoid having to rely on type inference and the code is more clear, or if you also have the expectation that we’ll generate a type-specialized version of the body of the function in question which you would expect to be more efficient than the fully generic version?
>> 
>> Do you imagine this supporting a scenario where only some of the type parameters are given explicitly and others are inferred, or would this only be supported in the case where all type parameters were given explicitly?
>> 
>> What if some of those type parameters were themselves generics? For example:
>>   func callee<T : SignedInteger, U : AnotherProtocol>(x: T, y: U) { … }
>>   func caller<T : AnotherProtocol>(x: T) {
>>     let f = bar<Int, T> // supported
>>     f(3, x)
>>   }
>> 
>> Mark
>> 
>>> 
>>> David
>>> 
>>> Allow explicit specialization of generic functions
>>> 
>>> Proposal: SE-XXXX <https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-allow-explicit-specialization-generic-functions.md>
>>> Author: David Hart <https://github.com/hartbit>, Douglas Gregor <https://github.com/DougGregor>
>>> Status: TBD
>>> Review manager: TBD
>>>  <https://github.com/hartbit/swift-evolution/tree/allow-explicit-types-generic-functions#introduction>Introduction
>>> 
>>> This proposal allows bypassing the type inference engine and explicitly specializing type arguments of generic functions. 
>>> 
>>>  <https://github.com/hartbit/swift-evolution/tree/allow-explicit-types-generic-functions#motivation>Motivation
>>> 
>>> In Swift, generic type parameters are inferred by the argument or return value types as follows:
>>> 
>>> func foo<T>(t: T) { ... }
>>> 
>>> foo(5) // infers T = Int
>>> There exists certain scenarios when a programmer wants to explicitly specialize a generic function. Swift does not allow it, so we resort to giving hints to the inference engine:
>>> 
>>> let f1 = foo as ((Int) -> Void)
>>> let f2: (Int) -> Void = foo
>>> let f3 = foo<Int> // error: Cannot explicitly specialize a generic function
>>> 
>>> func bar<T>() -> T { ... }
>>> 
>>> let b1 = bar() as Int
>>> let b2: Int = bar()
>>> let b3 = bar<Int>() // error: Cannot explicitly specialize a generic function
>>> This behaviour is not very consistent with generic types which allow specialization:
>>> 
>>> let array: Array<Int> = Array<Int>(arrayLiteral: 1, 2, 3)
>>> Therefore, this proposal seeks to make the above errors valid specializations:
>>> 
>>> let f3 = foo<Int> // explicitly specialized to (Int) -> Void 
>>> let b3 = bar<Int>() // explicitly specialized to () -> Int 
>>> An ambiguous scenario arrises when we wish to specialize initializer functions:
>>> 
>>> struct Foo<T: RawRepresentable where T.RawValue == String> {
>>>     let storage: T
>>> 
>>>     init<U: CustomStringConvertible>(_ value: U) {
>>>         storage = T(rawValue: value.description)!
>>>     }
>>> }
>>> 
>>> enum Bar: String, CustomStringConvertible {
>>>     case foobar = "foo"
>>> 
>>>     var description: String {
>>>         return self.rawValue
>>>     }
>>> }
>>> 
>>> let a = Foo<Bar>(Bar.foobar)
>>> Does this specialization specialize the struct's or the initializer's generic type? The proposal solves this ambiguity by requiring initializer generic type specialization to use the init syntax:
>>> 
>>> let a = Foo<Bar>.init<Bar>(Bar.foobar)
>>>  <https://github.com/hartbit/swift-evolution/tree/allow-explicit-types-generic-functions#detailed-design>Detailed Design
>>> 
>>> Function calls are fairly straight forward and have their grammar modified as follows:
>>> 
>>> function-call-expression → postfix-expression­ generic-argument-clause­opt parenthesized-expression
>>> 
>>> function-call-expression → postfix-expression generic-argument-clause­opt ­parenthesized-expression­opt ­trailing-closure­
>>> 
>>> To allow initializers to be called with explicit specialization, we need to use the Initializer Expression. Its grammar is modified to:
>>> 
>>> initializer-expression → postfix-expression­ . ­init­ generic-argument-clause­opt
>>> 
>>> initializer-expression → postfix-expression­ . ­init­ generic-argument-clause­opt ( ­argument-names­ )
>>> 
>>>  <https://github.com/hartbit/swift-evolution/tree/allow-explicit-types-generic-functions#impact-on-existing-code>Impact on Existing Code
>>> 
>>> This proposal is purely additive and will have no impact on existing code.
>>> 
>>>  <https://github.com/hartbit/swift-evolution/tree/allow-explicit-types-generic-functions#alternatives-considered>Alternatives Considered
>>> 
>>> Not adopting this proposal for Swift.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 

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