I think I like the explicitness of a required <> as well. (It reminds me of
Java, where you can leave out the parameter when the type is known.)
I am however not sure if we could add this without breaking current valid Swift
3 syntax. The following three statements are correct in Swift 3:
let one = X<Int>()
let two: X = X<Int>()
let three: X<Int> = X()
Only the following one is (obviously) incorrect:
let four: X = X()
If we would require empty brackets, even if the type can be inferred, I could
see example three stop working.
> On 23 Jan 2017, at 19:41, Trent Nadeau via swift-evolution
> <[email protected]> wrote:
>
> The proposal looks good to me with one possible concern. I'm leaning toward
> types that use the defaults should still require the angle brackets, X<>.
> This makes it clear that you're using a generic type. That leads me to think
> that the examples Doug gave should be an error as the explicit types on the
> `let`s should either be omitted completely or fully specified (as X<>,
> X<Double>, X<Int>, etc.).
>
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi Everyone,
>>>
>>> I've opened a PR (https://github.com/apple/swift-evolution/pull/591
>>> <https://github.com/apple/swift-evolution/pull/591>) proposing default
>>> generic arguments which I think would be nice addition to the language.
>>> They are also mentioned in "Generic manifesto".
>>>
>>> The proposal is focusing around generic types. Generic functions are not
>>> coved by the proposal and I don't think that we need default generic
>>> arguments in generic functions as all the types are always part of the
>>> function signature so the compiler can always infer them. One corner case
>>> might be if using default argument values in which case support for default
>>> generic arguments in functions might be useful.
>>
>> The proposal looks fairly straightforward and reasonable. One thing to think
>> about is how it interacts with type inference. For example, consider these
>> examples:
>>
>> struct X<T = Int> { }
>>
>> func f1() -> X<Double> { return X() }
>>
>> func f2() -> X<Int> { return X() }
>> func f2() -> X<Double> { return X() }
>>
>> func f3<T>(_: T) -> X<T> { return X() }
>>
>> let x1: X = f1() // okay: x1 has type X<Double>?
>> let x2: X = f2() // ambiguous?
>> let x3a: X = f3(1.5) // okay: x3a has type X<Double>?
>> let x3b: X = f3(1) // okay: x3a has type X<Int>?
>>
>> The type checker already has some notion of “if you can’t infer a particular
>> type, fill in a default” that is used for literals. That rule could be used
>> here… or we could do something else. This should be discussed in the
>> proposal.
>>
>> Thanks for working on this!
>
> There's an interesting parallel to the default behavior of literals. The type
> of a number or string literal is inferred from type context, or falls back to
> a default type like Int or String if that doesn't come up with an answer. You
> could think of that of saying the 'Self' type of the protocol constraint has
> a default (and maybe that's how we'd generalize the "default type for a
> protocol" feature if we wanted to.) It makes sense to me to follow a similar
> model for generic parameter defaults; that way, there's one consistent rule
> that applies.
>
> -Joe
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
>
> --
> Trent Nadeau
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
