Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

The proposal has been refactored to include all the things we have
discussed here. Thanks everyone for your feedback. If I've missed
something, please shout.

On Wed, Feb 1, 2017 at 7:35 AM, Srđan Rašić  wrote:

> Hah, did I really do that :( I completely missed the fact that `let foo:
> Optional = 42` is supported at the moment. I've been programming in Swift
> in day zero, but never really used such syntax.
>
> I'll update the PR, thanks for your feedback.
>
> ons. 1. feb. 2017 kl. 00.05 skrev Xiaodi Wu :
>
>> I have concerns about these revisions. It seems you've entirely rejected
>> all the options that Alexis has laid out very clearly, and instead you've
>> come up with your own rules which are backwards-incompatible with Swift 3.
>>
>> For instance, the rule "No type inference will happen in type
>> declarations" is source-breaking, because type inference currently happens
>> in type declarations. You would break every instance of `let foo: Optional
>> = 42`.
>>
>> I would urge you to incorporate Alexis's very clear analysis and then
>> adopt one of the options he laid out, i.e., either "prefer user" or "do
>> what I mean." Alternatively, if you like none of his options, I believe
>> that requiring `<>` to be appended for entirely default arguments would
>> avoid the issue altogether. Or, if you don't even want to require that, you
>> can push the whole problem down the road by specifying that, for now, the
>> first generic type cannot have a default. We can then relax the rules later.
>>
>>
>> On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić 
>> wrote:
>>
>> I updated the proposal with the things we discussed so far. Have to do
>> some more polishing, but feel free to throw your critique of what I have so
>> far.
>>
>> On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu  wrote:
>>
>> Oh, it's precisely my confidence that a good error message can be devised
>> which makes me ponder whether "prefer user" is the ideal rule. Having a
>> stricter rule isn't necessarily bad if the error message makes it easy to
>> remedy.
>>
>> In your example, "prefer user" would object at the line where you make
>> your Something. I think that makes for a much cleaner error. By contrast,
>> DWIM necessitates the acrobatics you show above, where the compiler will
>> have to keep track of a defaulted type for each variable as long as it's in
>> scope and propose remote fix-its at the declaration site based on how it's
>> later used. Now what happens if there's an action() that takes only
>> Something arguments and an action2() that takes only Something
>> arguments? Will you have an alternating cycle of fix-its that don't fix the
>> problem?
>>
>>
>> On Fri, Jan 27, 2017 at 18:07 Karl Wagner  wrote:
>>
>>
>> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Cool, thanks--that makes sense.
>>
>> Personally, although DWIM is appealing, I think if we are to go all-out
>> on your stance that "adding a default to an existing type parameter should
>> be a strict source-breaking change," then "prefer user" is the one rule
>> that maximally clarifies the scenario. With that rule, in the evolution
>> scenarios that I brought up, either the user-specified default and the
>> inferred literal type line up perfectly or it is guaranteed to be
>> source-breaking. IMO, that consistency would bring more clarity than DWIM,
>> which might prompt a user to be confused why sometimes the compiler "gets
>> it" and other times it doesn’t.
>>
>>
>> I’m not sure, I think it will be easy enough for users to figure out
>> where the problem is because it will create a type-mismatch.
>> When type mismatches occur, the only place to look is the variable
>> definition, because that is where the type is defined.
>>
>> This is such a narrow case that I’m sure we can provide good diagnostics
>> for it. The pattern could be:
>>
>> - A generic parameter mismatch (i.e. trying to use a value of type
>> MyType where type MyType is expected), and
>> - X and Y are both {Whatever}LiteralConvertible, and
>> - X is the default type bound to that parameter, and
>> - the value was initialised using a {Whatever} literal, where an instance
>> of the parameter was expected
>>
>> In that case, we could introduce a simple fix-it: replacing one of the
>> literal values with "(literal as Y)”
>>
>> for example:
>>
>> struct 

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

> On Jan 27, 2017, at 4:43 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Current alternative to default generic arguments is typealias, like 
> basic_string and string in C++:
> 
> struct BasicBigInt { ... }
> typealias BigInt = BasicBigInt
This is a really great point, but it should be noted that this is only 
sufficient to accomplish source-stability. Once the standard library starts 
providing ABI stability, this solution won’t work for it — the type of BigInt 
will become BasicBigInt which will change mangling and other things. 

First-class generic defaults, on the other hand, have the potential to be built 
out so that any binary compiled against the old type definition continues to 
work. The details of what this looks like depends on precisely how the final 
ABI shakes out.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

Hah, did I really do that :( I completely missed the fact that `let foo:
Optional = 42` is supported at the moment. I've been programming in Swift
in day zero, but never really used such syntax.

I'll update the PR, thanks for your feedback.

ons. 1. feb. 2017 kl. 00.05 skrev Xiaodi Wu :

> I have concerns about these revisions. It seems you've entirely rejected
> all the options that Alexis has laid out very clearly, and instead you've
> come up with your own rules which are backwards-incompatible with Swift 3.
>
> For instance, the rule "No type inference will happen in type
> declarations" is source-breaking, because type inference currently happens
> in type declarations. You would break every instance of `let foo: Optional
> = 42`.
>
> I would urge you to incorporate Alexis's very clear analysis and then
> adopt one of the options he laid out, i.e., either "prefer user" or "do
> what I mean." Alternatively, if you like none of his options, I believe
> that requiring `<>` to be appended for entirely default arguments would
> avoid the issue altogether. Or, if you don't even want to require that, you
> can push the whole problem down the road by specifying that, for now, the
> first generic type cannot have a default. We can then relax the rules later.
>
>
> On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić 
> wrote:
>
> I updated the proposal with the things we discussed so far. Have to do
> some more polishing, but feel free to throw your critique of what I have so
> far.
>
> On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu  wrote:
>
> Oh, it's precisely my confidence that a good error message can be devised
> which makes me ponder whether "prefer user" is the ideal rule. Having a
> stricter rule isn't necessarily bad if the error message makes it easy to
> remedy.
>
> In your example, "prefer user" would object at the line where you make
> your Something. I think that makes for a much cleaner error. By contrast,
> DWIM necessitates the acrobatics you show above, where the compiler will
> have to keep track of a defaulted type for each variable as long as it's in
> scope and propose remote fix-its at the declaration site based on how it's
> later used. Now what happens if there's an action() that takes only
> Something arguments and an action2() that takes only Something
> arguments? Will you have an alternating cycle of fix-its that don't fix the
> problem?
>
>
> On Fri, Jan 27, 2017 at 18:07 Karl Wagner  wrote:
>
>
> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Cool, thanks--that makes sense.
>
> Personally, although DWIM is appealing, I think if we are to go all-out on
> your stance that "adding a default to an existing type parameter should be
> a strict source-breaking change," then "prefer user" is the one rule that
> maximally clarifies the scenario. With that rule, in the evolution
> scenarios that I brought up, either the user-specified default and the
> inferred literal type line up perfectly or it is guaranteed to be
> source-breaking. IMO, that consistency would bring more clarity than DWIM,
> which might prompt a user to be confused why sometimes the compiler "gets
> it" and other times it doesn’t.
>
>
> I’m not sure, I think it will be easy enough for users to figure out where
> the problem is because it will create a type-mismatch.
> When type mismatches occur, the only place to look is the variable
> definition, because that is where the type is defined.
>
> This is such a narrow case that I’m sure we can provide good diagnostics
> for it. The pattern could be:
>
> - A generic parameter mismatch (i.e. trying to use a value of type
> MyType where type MyType is expected), and
> - X and Y are both {Whatever}LiteralConvertible, and
> - X is the default type bound to that parameter, and
> - the value was initialised using a {Whatever} literal, where an instance
> of the parameter was expected
>
> In that case, we could introduce a simple fix-it: replacing one of the
> literal values with "(literal as Y)”
>
> for example:
>
> struct 

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

I have concerns about these revisions. It seems you've entirely rejected
all the options that Alexis has laid out very clearly, and instead you've
come up with your own rules which are backwards-incompatible with Swift 3.

For instance, the rule "No type inference will happen in type declarations"
is source-breaking, because type inference currently happens in type
declarations. You would break every instance of `let foo: Optional = 42`.

I would urge you to incorporate Alexis's very clear analysis and then adopt
one of the options he laid out, i.e., either "prefer user" or "do what I
mean." Alternatively, if you like none of his options, I believe that
requiring `<>` to be appended for entirely default arguments would avoid
the issue altogether. Or, if you don't even want to require that, you can
push the whole problem down the road by specifying that, for now, the first
generic type cannot have a default. We can then relax the rules later.


On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić  wrote:

> I updated the proposal with the things we discussed so far. Have to do
> some more polishing, but feel free to throw your critique of what I have so
> far.
>
> On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu  wrote:
>
>> Oh, it's precisely my confidence that a good error message can be devised
>> which makes me ponder whether "prefer user" is the ideal rule. Having a
>> stricter rule isn't necessarily bad if the error message makes it easy to
>> remedy.
>>
>> In your example, "prefer user" would object at the line where you make
>> your Something. I think that makes for a much cleaner error. By contrast,
>> DWIM necessitates the acrobatics you show above, where the compiler will
>> have to keep track of a defaulted type for each variable as long as it's in
>> scope and propose remote fix-its at the declaration site based on how it's
>> later used. Now what happens if there's an action() that takes only
>> Something arguments and an action2() that takes only Something
>> arguments? Will you have an alternating cycle of fix-its that don't fix the
>> problem?
>>
>>
>> On Fri, Jan 27, 2017 at 18:07 Karl Wagner  wrote:
>>
>>>
>>> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Cool, thanks--that makes sense.
>>>
>>> Personally, although DWIM is appealing, I think if we are to go all-out
>>> on your stance that "adding a default to an existing type parameter should
>>> be a strict source-breaking change," then "prefer user" is the one rule
>>> that maximally clarifies the scenario. With that rule, in the evolution
>>> scenarios that I brought up, either the user-specified default and the
>>> inferred literal type line up perfectly or it is guaranteed to be
>>> source-breaking. IMO, that consistency would bring more clarity than DWIM,
>>> which might prompt a user to be confused why sometimes the compiler "gets
>>> it" and other times it doesn’t.
>>>
>>>
>>> I’m not sure, I think it will be easy enough for users to figure out
>>> where the problem is because it will create a type-mismatch.
>>> When type mismatches occur, the only place to look is the variable
>>> definition, because that is where the type is defined.
>>>
>>> This is such a narrow case that I’m sure we can provide good diagnostics
>>> for it. The pattern could be:
>>>
>>> - A generic parameter mismatch (i.e. trying to use a value of type
>>> MyType where type MyType is expected), and
>>> - X and Y are both {Whatever}LiteralConvertible, and
>>> - X is the default type bound to that parameter, and
>>> - the value was initialised using a {Whatever} literal, where an
>>> instance of the parameter was expected
>>>
>>> In that case, we could introduce a simple fix-it: replacing one of the
>>> literal values with "(literal as Y)”
>>>
>>> for example:
>>>
>>> struct 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

I updated the proposal with the things we discussed so far. Have to do some
more polishing, but feel free to throw your critique of what I have so far.

On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu  wrote:

> Oh, it's precisely my confidence that a good error message can be devised
> which makes me ponder whether "prefer user" is the ideal rule. Having a
> stricter rule isn't necessarily bad if the error message makes it easy to
> remedy.
>
> In your example, "prefer user" would object at the line where you make
> your Something. I think that makes for a much cleaner error. By contrast,
> DWIM necessitates the acrobatics you show above, where the compiler will
> have to keep track of a defaulted type for each variable as long as it's in
> scope and propose remote fix-its at the declaration site based on how it's
> later used. Now what happens if there's an action() that takes only
> Something arguments and an action2() that takes only Something
> arguments? Will you have an alternating cycle of fix-its that don't fix the
> problem?
>
>
> On Fri, Jan 27, 2017 at 18:07 Karl Wagner  wrote:
>
>>
>> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Cool, thanks--that makes sense.
>>
>> Personally, although DWIM is appealing, I think if we are to go all-out
>> on your stance that "adding a default to an existing type parameter should
>> be a strict source-breaking change," then "prefer user" is the one rule
>> that maximally clarifies the scenario. With that rule, in the evolution
>> scenarios that I brought up, either the user-specified default and the
>> inferred literal type line up perfectly or it is guaranteed to be
>> source-breaking. IMO, that consistency would bring more clarity than DWIM,
>> which might prompt a user to be confused why sometimes the compiler "gets
>> it" and other times it doesn’t.
>>
>>
>> I’m not sure, I think it will be easy enough for users to figure out
>> where the problem is because it will create a type-mismatch.
>> When type mismatches occur, the only place to look is the variable
>> definition, because that is where the type is defined.
>>
>> This is such a narrow case that I’m sure we can provide good diagnostics
>> for it. The pattern could be:
>>
>> - A generic parameter mismatch (i.e. trying to use a value of type
>> MyType where type MyType is expected), and
>> - X and Y are both {Whatever}LiteralConvertible, and
>> - X is the default type bound to that parameter, and
>> - the value was initialised using a {Whatever} literal, where an instance
>> of the parameter was expected
>>
>> In that case, we could introduce a simple fix-it: replacing one of the
>> literal values with "(literal as Y)”
>>
>> for example:
>>
>> struct 

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

Oh, it's precisely my confidence that a good error message can be devised
which makes me ponder whether "prefer user" is the ideal rule. Having a
stricter rule isn't necessarily bad if the error message makes it easy to
remedy.

In your example, "prefer user" would object at the line where you make your
Something. I think that makes for a much cleaner error. By contrast, DWIM
necessitates the acrobatics you show above, where the compiler will have to
keep track of a defaulted type for each variable as long as it's in scope
and propose remote fix-its at the declaration site based on how it's later
used. Now what happens if there's an action() that takes only
Something arguments and an action2() that takes only Something
arguments? Will you have an alternating cycle of fix-its that don't fix the
problem?

On Fri, Jan 27, 2017 at 18:07 Karl Wagner  wrote:

>
> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Cool, thanks--that makes sense.
>
> Personally, although DWIM is appealing, I think if we are to go all-out on
> your stance that "adding a default to an existing type parameter should be
> a strict source-breaking change," then "prefer user" is the one rule that
> maximally clarifies the scenario. With that rule, in the evolution
> scenarios that I brought up, either the user-specified default and the
> inferred literal type line up perfectly or it is guaranteed to be
> source-breaking. IMO, that consistency would bring more clarity than DWIM,
> which might prompt a user to be confused why sometimes the compiler "gets
> it" and other times it doesn’t.
>
>
> I’m not sure, I think it will be easy enough for users to figure out where
> the problem is because it will create a type-mismatch.
> When type mismatches occur, the only place to look is the variable
> definition, because that is where the type is defined.
>
> This is such a narrow case that I’m sure we can provide good diagnostics
> for it. The pattern could be:
>
> - A generic parameter mismatch (i.e. trying to use a value of type
> MyType where type MyType is expected), and
> - X and Y are both {Whatever}LiteralConvertible, and
> - X is the default type bound to that parameter, and
> - the value was initialised using a {Whatever} literal, where an instance
> of the parameter was expected
>
> In that case, we could introduce a simple fix-it: replacing one of the
> literal values with "(literal as Y)”
>
> for example:
>
> struct 

Re: [swift-evolution] Default Generic Arguments

[Karl Wagner via swift-evolution]

> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Cool, thanks--that makes sense.
> 
> Personally, although DWIM is appealing, I think if we are to go all-out on 
> your stance that "adding a default to an existing type parameter should be a 
> strict source-breaking change," then "prefer user" is the one rule that 
> maximally clarifies the scenario. With that rule, in the evolution scenarios 
> that I brought up, either the user-specified default and the inferred literal 
> type line up perfectly or it is guaranteed to be source-breaking. IMO, that 
> consistency would bring more clarity than DWIM, which might prompt a user to 
> be confused why sometimes the compiler "gets it" and other times it doesn’t.

I’m not sure, I think it will be easy enough for users to figure out where the 
problem is because it will create a type-mismatch.
When type mismatches occur, the only place to look is the variable definition, 
because that is where the type is defined.

This is such a narrow case that I’m sure we can provide good diagnostics for 
it. The pattern could be:

- A generic parameter mismatch (i.e. trying to use a value of type MyType 
where type MyType is expected), and
- X and Y are both {Whatever}LiteralConvertible, and
- X is the default type bound to that parameter, and 
- the value was initialised using a {Whatever} literal, where an instance of 
the parameter was expected

In that case, we could introduce a simple fix-it: replacing one of the literal 
values with "(literal as Y)”

for example:

struct 

Re: [swift-evolution] Default Generic Arguments

[David Sweeris via swift-evolution]

> On Jan 27, 2017, at 1:43 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Current alternative to default generic arguments is typealias, like 
> basic_string and string in C++:
> 
> struct BasicBigInt { ... }
> typealias BigInt = BasicBigInt
> It’s not that ugly. It keeps type inference rules simpler, easier to 
> understand and more explicit.
> As someone noted, current type inference for generic initializers works 
> satisfactory in 99% cases. Is it really worth it to try to cover 99.9% at the 
> cost of complexity of type inference rules?
> 
> On the other hand, in the wild, there may exist types with 3 or even more 
> generic parameters that have sensible default values. [Research needed]
> For such complex cases, I think, it makes sense to add default generic 
> parameters only together with generic parameter labels.
> Also, in such cases, functions on types could often help. And that story is 
> even out of scope of Swift 4 Phase 2.
> 

If we could overload the type's name, I think that’d solve my use-case pretty 
much completely:
protocol Endian {}
class BigEndian : Endian {}
class LittleEndian : Endian {}
class NativeEndian : Endian {}
struct BigInt {...} //Made-up syntax for 
indicating the generic parameters’ labels should be the same both internally 
and externally
typealias BigInt = BigInt where T: Integer
typealias BigInt = BigInt

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Anton Zhilin via swift-evolution]

Current alternative to default generic arguments is typealias, like
basic_string and string in C++:

struct BasicBigInt { ... }
typealias BigInt = BasicBigInt

It’s not *that* ugly. It keeps type inference rules simpler, easier to
understand and more explicit.
As someone noted, current type inference for generic initializers works
satisfactory in 99% cases. Is it really worth it to try to cover 99.9% at
the cost of complexity of type inference rules?

On the other hand, in the wild, there may exist types with 3 or even more
generic parameters that have sensible default values. [Research needed]
For such complex cases, I think, it makes sense to add default generic
parameters *only* together with generic parameter labels.
Also, in such cases, functions on types could often help. And that story is
even out of scope of Swift 4 Phase 2.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

I don’t have much skin in the nuance of PU vs DWIM since, as far as I can tell, 
it’s backwards compatible to update from PU to DWIM. So we could conservatively 
adopt PU and then migrate to DWIM if that's found to be intolerable. I expect 
it will be intolerable, though.

Also, language subtlety thing here: there’s lots of things which are *strictly* 
source breaking changes, but tend to work out 99% of the time anyway because of 
things like inference. I’m not at all opposed to making things work out 99.9% 
of the time instead. For instance, if I changed the Iterator type some 
collection yielded, almost no one would notice because they just pass it into a 
for loop or call a standard Sequence method on it. Still, strictly a source 
breaking change. Someone’s code could stop compiling.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

Cool, thanks--that makes sense.

Personally, although DWIM is appealing, I think if we are to go all-out on
your stance that "adding a default to an existing type parameter should be
a strict source-breaking change," then "prefer user" is the one rule that
maximally clarifies the scenario. With that rule, in the evolution
scenarios that I brought up, either the user-specified default and the
inferred literal type line up perfectly or it is guaranteed to be
source-breaking. IMO, that consistency would bring more clarity than DWIM,
which might prompt a user to be confused why sometimes the compiler "gets
it" and other times it doesn't.
On Thu, Jan 26, 2017 at 18:15 Alexis  wrote:

>
> On Jan 26, 2017, at 4:26 PM, Xiaodi Wu  wrote:
>
> Very interesting point, Alexis. So can you reiterate again which of the
> four options you outlined earlier support this use case? And if there are
> multiple, which would be the most consistent with the rest of the language?
>
>
> Both “prefer user” and “DWIM” are consistent with my desired solution for
> this specific problem (they pick Int64). DWIM seems more consistent with
> the rest of Swift to me in that it tries harder to find a reasonable
> interpretation of your code before giving up. I think it also ends up
> having the simplest implementation in the current compiler. You can
> potentially just add a new tie-breaker if-statement in this code:
> https://github.com/apple/swift/blob/master/lib/Sema/CSRanking.cpp#L1010
>
> Something to the affect of “if one of these was recommended by a generic
> default, that one’s better”. This of course requires threading that
> information through the compiler.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

> On Jan 26, 2017, at 4:26 PM, Xiaodi Wu  wrote:
> 
> Very interesting point, Alexis. So can you reiterate again which of the four 
> options you outlined earlier support this use case? And if there are 
> multiple, which would be the most consistent with the rest of the language?
> 

Both “prefer user” and “DWIM” are consistent with my desired solution for this 
specific problem (they pick Int64). DWIM seems more consistent with the rest of 
Swift to me in that it tries harder to find a reasonable interpretation of your 
code before giving up. I think it also ends up having the simplest 
implementation in the current compiler. You can potentially just add a new 
tie-breaker if-statement in this code: 
https://github.com/apple/swift/blob/master/lib/Sema/CSRanking.cpp#L1010 


Something to the affect of “if one of these was recommended by a generic 
default, that one’s better”. This of course requires threading that information 
through the compiler.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

Very interesting point, Alexis. So can you reiterate again which of the
four options you outlined earlier support this use case? And if there are
multiple, which would be the most consistent with the rest of the language?

And Srdan, could you incorporate that information into your discussion?
On Thu, Jan 26, 2017 at 12:59 Srđan Rašić  wrote:

> That's a very good point Alexis and makes sense to me. I'll updated the
> proposal with that in mind and revise my examples.
>
> On Thu, Jan 26, 2017 at 7:06 PM, Alexis  wrote:
>
>
> On Jan 25, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>
> Srdan, I'm afraid I don't understand your discussion. Can you simplify it
> for me by explaining your proposed solution in terms of Alexis's examples
> below?
>
> ```
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

That's a very good point Alexis and makes sense to me. I'll updated the
proposal with that in mind and revise my examples.

On Thu, Jan 26, 2017 at 7:06 PM, Alexis  wrote:

>
> On Jan 25, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>
> Srdan, I'm afraid I don't understand your discussion. Can you simplify it
> for me by explaining your proposed solution in terms of Alexis's examples
> below?
>
> ```
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func 

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

> On Jan 25, 2017, at 8:15 PM, Xiaodi Wu  wrote:
> 
> Srdan, I'm afraid I don't understand your discussion. Can you simplify it for 
> me by explaining your proposed solution in terms of Alexis's examples below?
> 
> ```
> // Example 1: user supplied default is IntegerLiteralConvertible
> 
> func 

Re: [swift-evolution] Default Generic Arguments

[David Sweeris via swift-evolution]

> On Jan 24, 2017, at 15:33, Xiaodi Wu  wrote:
> 
> As I replied above, this doesn't work IMO because omitted generic arguments 
> are inferred, and that can't change without being hugely source-breaking.
> 
> I think it's absolutely essential that adding a default to my library doesn't 
> change the behavior of code that uses my library. That's currently the case, 
> afaict, for all default arguments, and so I think it's essential here.

There is a difference, though, in that default values can't be inferred... 
Simply adding a default value for a function argument can't change the behavior 
of anything because, prior to adding it, any code that didn't provide that 
value wouldn't have compiled.

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Karl Wagner via swift-evolution]

> On 26 Jan 2017, at 02:15, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Srdan, I'm afraid I don't understand your discussion. Can you simplify it for 
> me by explaining your proposed solution in terms of Alexis's examples below?
> 
> ```
> // Example 1: user supplied default is IntegerLiteralConvertible
> 
> func 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

Thanks for your questions Xiaodi, I might have missed some scenarios.
I've had some rethinking and here are the conclusions.
It's a slight refinement of the idea I had in the previous mail. Bear with
me :)

If we have

func process(_ t: T) {}

process(5)

 compiler will infer T as Int.

 Now we introduce a default argument

func process(_ t: T) {}

 and in order to keep source compatibility, if we do

process(5)

 we must again infer T as Int. That means that the inference should have
 priority over default arguments. That is in accordance with the rule that
 we defined earlier: if you can’t infer a particular type, fill in a
default.
 We are able to infer particular type, Int, so we do that.

 However, say we had

struct Storage: Integer {
init(_ t: T)
}

let s = Storage(5)

 and we wanted to introduce a default argument:

struct Storage: Integer {
init(_ t: T)
}

 What happens with `s`? This is essentially the same problem as previous,
 so the solution should also be same - we must infer Int.

 Would that be confusing for a developer? Maybe, but what is the
 alternative? Using the default would make no sense because then

let s = Storage("ops")

 would fail to compile. So inference in such cases is a must. Similar
 problem would be observed with inheritance and/or protocol adoption.

protocol P {}
struct R: P {}

struct Storage: Integer {
init(_ t: T)
}

let s = Storage(R())

 Is T infered to R or to P? To keep source compatibility, we must infer R.

 In other words, I agree with you Xiaodi.

 Now to my argument about type declarations. Say we now do

let s: Storage = Storage(R())

 In that case T must be infered to P because type declaration must not be
 affected by inference. Storage on the left must be treated as Storage.
 If that were not the case, consider what would happen if you upgrade local
 variable to a propery.

class T {
let s: Storage

init() {
s = Storage(R())
}
}

 What is infered for T must not change by making such upgrade and allowing
 type inferrence in initializer to affect propery type would make no sense.

 Thus, there has to be a rule that says:

(I) In type declarations, no inference happens. By omitting generic
arguments
one accepts the defaults.

 And to repeat our second rule:

(II) When instantiating generic type or calling generic function, by
omitting
generic arguments one lets the compiler specify generic arguments by
following
the principle: infer particular type if possible, fill in a default
otherwise.

 Let's go throught some more examples.

 Declaring a function like

func clear(_ storage: Storage)

 assumes `storage` to be of type Storage because of rule (I).

 Declaring a constant like

let s = Storage(R())

 will infer `s` to Storage becasue of (II), but

let s: Storage = Storage(R())

 would be considered identical to

let s: Storage = Storage(R())

 because T is defaulted to P and rule (I) is applied to the left hand side,
so
 rule (II) applies to right hand side by the infering type from left hand
side.

 We must also consider:

let s = Storage("123")

 This is simple. With rule (II) we infer Storage. However, if we do

let s: Storage = Storage("123")

 compiler must throw an error: cannot assign Storage to Storage.

 Next, consider following type

struct Storage: Integer {
init()
}

 If we do

let s = Storage()

 we should apply rule (II). In this case, no particular type can be infered
so
 we will fill in the default. Meaning that `s` would be Storage.

 What about generic function calls? Let's use the older example.

protocol P {}
struct R: P {}

struct Storage: Integer {
init(_ t: T)
}

func clear(_ storage: Storage)

 If we do

clear(Storage())

 we should use rule (II) to get the type. Here we don't have anything to
infer
 from so we should fill in the default. T = Storage.

 Doing

clear(Storage(R()))

 would use rule (II) to infer T as R.

 However, consider generic function with defaults:

func clear(_ storage: Storage)

 Now we have a defult R in function and a default P in the type. What if we
now do

clear(Storage())

 Should T be specialized to P or R? This is a conflict of defaults. I'd say
it should be
 resolved in the favour of function. In a way function that operates on
type X could be
 considered extension of that type and has more specific use case knowledge
of its
 arguments so the function preference should be accepted.

 So, trying to apply rule (II). There is nothing to infer, so we try to
fill in a default.
 We have two defaults - function says the default is R, struct says the
default is P.
 As we are resolving this in favour of the function - we chose R.

 Final example,

clear(Storage(R()))

 There are no conflicts here. By applying rule (II) we directly infer type
R and use it
 regardless of 

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

Srdan, I'm afraid I don't understand your discussion. Can you simplify it
for me by explaining your proposed solution in terms of Alexis's examples
below?

```
// Example 1: user supplied default is IntegerLiteralConvertible

func 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

That's a good example Alexis. I do agree that generic arguments are
inferred in a lot of cases, my point was that they should not be inferred
in "type declarations". Not sure what's the right terminology here, but I
mean following places:

(I) Variable/Constant declaration

  ```
  let x: X
  ```

(II) Property declaration

  ```
  struct T {
let x: X
  }
  ```

(III) Function declaration

  ```
  func a(x: X) -> X
  ```

(IV) Enumeration case declaration

  ```
  enum E {
case x(X)
  }
  ```

(V) Where clauses

  ```
  extensions E where A == X {}
  ```

In those cases `X` should always mean `X` if it was defined as `struct
X`. That's all my rule says. Sorry for not being clear in the last
email :)

As for the other cases, mostly those where an instance is created,
inference should be applied.

Let's go through your examples. Given

struct BigInt: Integer {
  var storage: Array = []
}

func process(_ input: BigInt) -> BigInt { ... }

what happens with `let val1 = process(BigInt())`? I think this is actually
the same problem as what happens in case of `let x = BigInt()`.

In such case my rule does not apply as we don't have full type declaration.
In `let x = BigInt()` type is not defined at all, while in `func process(_ input: BigInt) -> BigInt { ... }` type is explicitly
weakened or "undefaulted" if you will.

We should introduce new rule for such cases and allowing `Storage=Int`
default to participate in such expressions would make sense. As you said,
it also solves second example: let val2 = process(0).

I guess this would be the problem we thought we were solving initially and
in that case I think the solution should be what Doug suggested: if you
can’t infer a particular type, fill in a default.

Of course, if the default conflicts with the generic constraint, it would
not be filled in and it would throw an error.

For the sake of completeness,

func fastProcess(_ input: BigInt) -> BigInt { ... }
let val3 = fastProcess(BigInt())

would certainly infer the type from context as my rule does not apply to
initializers. It would infer BigInt.

As for your last example, I guess we can't do anything about that and
that's ok.


On Wed, Jan 25, 2017 at 7:50 PM, Alexis  wrote:

> Yes, I agree with Xiaodi here. I don’t think this particular example is
> particularly compelling. Especially because it’s not following the full
> evolution of the APIs and usage, which is critical for understanding how
> defaults should work.
>
>
> Let's look at the evolution of an API and its consumers with the example
> of a BigInt:
>
>
> struct BigInt: Integer {
>   var storage: Array = []
> }
>
>
> which a consumer is using like:
>
>
> func process(_ input: BigInt) -> BigInt { ... }
> let val1 = process(BigInt())
> let val2 = process(0)
>
>
> Ok that's all fairly straightforward. Now we decide that BigInt should
> expose its storage type for power-users:
>
>
> struct BigInt: Integer {
>   var storage: Array = []
> }
>
>
> Let's make sure our consumer still works:
>
>
> func process(_ input: BigInt) -> BigInt { ... }
> let val1 = process(BigInt())
> let val2 = process(0)
>
>
> Ok BigInt in process’s definition now means BigInt, so this still all
> works fine. Perfect!
>
>
> But then the developer of the process function catches wind of this new
> power user feature, and wants to support it.
> So they too become generic:
>
>
> func process(_ input: BigInt) -> BigInt { ... }
>
>
> The usage sites are now more complicated, and whether they should compile
> is unclear:
>
>
> let val1 = process(BigInt())
> let val2 = process(0)
>
>
> For val1 you can take a hard stance with your rule: BigInt() means
> BigInt(), and that will work. But for val2 this rule doesn't work,
> because no one has written BigInt unqualified. However if you say that the
> `Storage=Int` default is allowed to participate in this expression, then we
> can still find the old behaviour by defaulting to it when we discover
> Storage is ambiguous.
>
> We can also consider another power-user function:
>
>
> func fastProcess(_ input: BigInt) -> BigInt { ... }
> let val3 = fastProcess(BigInt())
>
>
> Again, we must decide the interpretation of this. If we take the
> interpretation that BigInt() has an inferred type, then the type checker
> should discover that BigInt is the correct result. If however we
> take stance that BigInt() means BigInt(), then we'll get a type
> checking error which our users will consider ridiculous: *of course* they
> wanted a BigInt here!
>
> We do however have the problem that this won’t work:
>
>
> let temp = BigInt()
> fastProcess(temp) // ERROR — expected BigInt, found BigInt
>
>
> But that’s just as true for normal ints:
>
>
> let temp = 0
> takesAnInt64(temp) // ERROR — expected Int64, found Int
>
>
> Such is the limit of Swift’s inference scheme.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

Yes, I agree with Xiaodi here. I don’t think this particular example is 
particularly compelling. Especially because it’s not following the full 
evolution of the APIs and usage, which is critical for understanding how 
defaults should work.


Let's look at the evolution of an API and its consumers with the example of a 
BigInt:


struct BigInt: Integer {
  var storage: Array = []
}


which a consumer is using like:


func process(_ input: BigInt) -> BigInt { ... }
let val1 = process(BigInt())
let val2 = process(0) 


Ok that's all fairly straightforward. Now we decide that BigInt should expose 
its storage type for power-users:


struct BigInt: Integer {
  var storage: Array = []
}


Let's make sure our consumer still works:


func process(_ input: BigInt) -> BigInt { ... }
let val1 = process(BigInt())
let val2 = process(0) 


Ok BigInt in process’s definition now means BigInt, so this still all 
works fine. Perfect!


But then the developer of the process function catches wind of this new power 
user feature, and wants to support it.
So they too become generic:


func process(_ input: BigInt) -> BigInt { ... }


The usage sites are now more complicated, and whether they should compile is 
unclear:


let val1 = process(BigInt())
let val2 = process(0) 


For val1 you can take a hard stance with your rule: BigInt() means 
BigInt(), and that will work. But for val2 this rule doesn't work, because 
no one has written BigInt unqualified. However if you say that the 
`Storage=Int` default is allowed to participate in this expression, then we can 
still find the old behaviour by defaulting to it when we discover Storage is 
ambiguous.

We can also consider another power-user function:


func fastProcess(_ input: BigInt) -> BigInt { ... }
let val3 = fastProcess(BigInt())


Again, we must decide the interpretation of this. If we take the interpretation 
that BigInt() has an inferred type, then the type checker should discover that 
BigInt is the correct result. If however we take stance that BigInt() 
means BigInt(), then we'll get a type checking error which our users will 
consider ridiculous: *of course* they wanted a BigInt here!

We do however have the problem that this won’t work:


let temp = BigInt()
fastProcess(temp) // ERROR — expected BigInt, found BigInt 


But that’s just as true for normal ints:


let temp = 0
takesAnInt64(temp) // ERROR — expected Int64, found Int


Such is the limit of Swift’s inference scheme.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Karl Wagner via swift-evolution]

> On 24 Jan 2017, at 05:10, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> While it looks nicer without the angle brackets, that suggestion is 
> unresponsive to David's point that we need some way to distinguish defaulted 
> generic arguments from inferred generic arguments.
> 
> Consider:
> ```
> let a: Optional = 1 // Optional
> 
> enum FloatPreferringOptional {
>   case some(T)
>   case none
> }
> 
> let b: FloatPreferringOptional = 1
> // Does this give you an FloatPreferringOptional?
> ```
> 
> If the answer to the above question is "yes, T is inferred as Int" then we 
> need some way to express "give me the default for T, which is Float." If the 
> answer to the above question is "no" then we need some way to express "don't 
> give me the default; rather, infer type T from the right hand side."
> 
> 
> On Mon, Jan 23, 2017 at 6:30 PM, Matthew Johnson via swift-evolution 
> > wrote:
> This proposal looks good to me.  I have been looking forward to more flexible 
> generic arguments for a while.
> 
> I agree with previous commenters who prefer the option to leave off the angle 
> brackets when all parameters have defaults.
> 
> The proposal specifically mentions that the syntax is inspired by that of 
> function arguments.  This is good, but I wonder if maybe we should draw 
> further inspiration from function arguments and also add parameter labels for 
> generic arguments.  Both feel like low hanging fruit in the generics area 
> (correct me if I’m wrong about that) and it would be great to see both 
> enhancements make it into Swift 4.
> 
>> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution 
>> > wrote:
>> 
>> Hi Everyone,
>> 
>> I've opened a PR (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.
>> 
>> It would be great to hear your opinions and suggestions so I can refine the 
>> proposal.
>> ___
>> 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 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I was watching this talk recently by Bjarne Stroustrup 
(https://youtu.be/2egL4y_VpYg?t=26m34s 
), he was saying that when new things 
are added to a language, people tend to want very loud syntax just because it’s 
new and people want it to be obvious and fool-proof. That’s why C++ syntax is 
such a mess.

Personally, I’m fine leaving the angle brackets away if there is a default 
value. If the expected type is not the one inferred by the initialiser, you 
will hit compiler errors and be able to explicitly say which value the 
parameter should have. It’s not an unreasonable cognitive load.

- Karl


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

As I replied above, this doesn't work IMO because omitted generic arguments
are inferred, and that can't change without being hugely source-breaking.

I think it's absolutely essential that adding a default to my library
doesn't change the behavior of code that uses my library. That's currently
the case, afaict, for all default arguments, and so I think it's essential
here.


On Tue, Jan 24, 2017 at 17:26 Srđan Rašić via swift-evolution <
swift-evolution@swift.org> wrote:

> We are probably taking the wrong direction here and trying to solve the
> problem that does not need solving. We are discussing how to infer
> gereneric arguments in type declarations while we should not do that at
> all.
>
> Let me repeat Doug's examples:
>
>
> struct X { }
>
> func f1() -> X { return X() }
>
> func f2() -> X { return X() }
> func f2() -> X { return X() }
>
> func f3(_: T) -> X { return X() }
>
> let x1: X = f1()   // okay: x1 has type X?
> let x2: X = f2()   // ambiguous?
> let x3a: X = f3(1.5)   // okay: x3a has type X?
> let x3b: X = f3(1)   // okay: x3a has type X?
>
> Thinking about what the generic argument of X should be inferred to for
> x1, x2 and x3 is pointless. If one omits generic arguments in the variable
> declaration, one is accepting the defaults. In other words, doing let x: X
> = ... should always be treated as doing let x: X = ..., regardless of
> what we have on the right hand side. No inference should happen in this
> case. It would mean inferring already specified type.
>
> Why? Consider what happens if we define x as a property:
>
> struct Test {
>   let x: X
>
>   init() {
> x = f()
>   }
> }
>
> It would make no sense that the initialization in the initializer
> specializes the generic argument of the property, so for the sake of
> consistency we should not do it for the variables/constants either.
>
> Given that, we can solve Doug's example as:
>
> let x1: X = f1() // error: cannot assign X to X
>
> let x2: X = f2()   // ok: using X overload
> let x3a: X = f3(1.5)   // error like in x1
> let x3b: X = f3(1)   // ok because rhs is inferred as X
>
> I think this is the only valid way to go and it really simplifies things,
> both the understanding of how the feature works, but also the
> implementation.
>
> What do you think?
>
>
> tir. 24. jan. 2017 kl. 22.16 skrev David Sweeris :
>
>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for
> some discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func 

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

That does not comport with the definition of "default." I would disagree
with that treatment. Nor does it seem consistent with current syntax. If I
have a type Foo, then inference works when someone writes `let a: Foo =
...`. If I add a default to my type 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

We are probably taking the wrong direction here and trying to solve the
problem that does not need solving. We are discussing how to infer
gereneric arguments in type declarations while we should not do that at
all.

Let me repeat Doug's examples:


struct X { }

func f1() -> X { return X() }

func f2() -> X { return X() }
func f2() -> X { return X() }

func f3(_: T) -> X { return X() }

let x1: X = f1()   // okay: x1 has type X?
let x2: X = f2()   // ambiguous?
let x3a: X = f3(1.5)   // okay: x3a has type X?
let x3b: X = f3(1)   // okay: x3a has type X?

Thinking about what the generic argument of X should be inferred to for x1,
x2 and x3 is pointless. If one omits generic arguments in the variable
declaration, one is accepting the defaults. In other words, doing let x: X
= ... should always be treated as doing let x: X = ..., regardless of
what we have on the right hand side. No inference should happen in this
case. It would mean inferring already specified type.

Why? Consider what happens if we define x as a property:

struct Test {
  let x: X

  init() {
x = f()
  }
}

It would make no sense that the initialization in the initializer
specializes the generic argument of the property, so for the sake of
consistency we should not do it for the variables/constants either.

Given that, we can solve Doug's example as:

let x1: X = f1() // error: cannot assign X to X

let x2: X = f2()   // ok: using X overload
let x3a: X = f3(1.5)   // error like in x1
let x3b: X = f3(1)   // ok because rhs is inferred as X

I think this is the only valid way to go and it really simplifies things,
both the understanding of how the feature works, but also the
implementation.

What do you think?


tir. 24. jan. 2017 kl. 22.16 skrev David Sweeris :

>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for
> some discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func 

Re: [swift-evolution] Default Generic Arguments

[T.J. Usiyan via swift-evolution]

I like this approach as a first pass. It leaves room for other, more
forgiving strategies later and is relatively easy to explain.

On Tue, Jan 24, 2017 at 4:16 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See https://internals.rust-lang.org/t/interaction-of-
> user-defined-and-integral-fallbacks-with-inference/2496 for some
> discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func 

Re: [swift-evolution] Default Generic Arguments

[David Sweeris via swift-evolution]

> On Jan 24, 2017, at 11:41, Alexis via swift-evolution 
>  wrote:
> 
> It’s worth noting that the question of “how do these defaults interact with 
> other defaults” is an issue that has left this feature dead in the water in 
> the Rust language despite being accepted for inclusion two years ago. See 
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for some discussion of the issues at hand.
> 
> For those who don’t want to click that link, or are having trouble 
> translating the syntax/terms to Swift. The heart of Niko’s post is the 
> following (note: functions are used here for expedience; you can imagine 
> these are `inits` for a generic type if you wish):
> 
> // Example 1: user supplied default is IntegerLiteralConvertible
> 
> func 

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

It’s worth noting that the question of “how do these defaults interact with 
other defaults” is an issue that has left this feature dead in the water in the 
Rust language despite being accepted for inclusion two years ago. See 
https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
 

 for some discussion of the issues at hand.

For those who don’t want to click that link, or are having trouble translating 
the syntax/terms to Swift. The heart of Niko’s post is the following (note: 
functions are used here for expedience; you can imagine these are `inits` for a 
generic type if you wish):

// Example 1: user supplied default is IntegerLiteralConvertible

func 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

> If the answer to the above question is "yes, T is inferred as Int" then
we need some way to express "give me the default for T, which is Float."

I don't think that we need that. It would introduce a new level of
explicitness, "I want the default, but I don't care what the default is",
that is not really useful. If you don't care what the default type is, you
probably also don't care that you are defaulting. If you do care what the
default type is, you would explicitly sepecify it as `X`.


> If the answer to the above question is "no" then we need some way to
express "don't give me the default; rather, infer type T from the right
hand side."

That would be preferred behavior. Infer from the context if possible, use
default otherwise.


tir. 24. jan. 2017 kl. 05.11 skrev Xiaodi Wu :

> While it looks nicer without the angle brackets, that suggestion is
> unresponsive to David's point that we need some way to distinguish
> defaulted generic arguments from inferred generic arguments.
>
> Consider:
> ```
> let a: Optional = 1 // Optional
>
> enum FloatPreferringOptional {
>   case some(T)
>   case none
> }
>
> let b: FloatPreferringOptional = 1
> // Does this give you an FloatPreferringOptional?
> ```
>
> If the answer to the above question is "yes, T is inferred as Int" then we
> need some way to express "give me the default for T, which is Float." If
> the answer to the above question is "no" then we need some way to express
> "don't give me the default; rather, infer type T from the right hand side."
>
>
> On Mon, Jan 23, 2017 at 6:30 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This proposal looks good to me.  I have been looking forward to more
> flexible generic arguments for a while.
>
> I agree with previous commenters who prefer the option to leave off the
> angle brackets when all parameters have defaults.
>
> The proposal specifically mentions that the syntax is inspired by that of
> function arguments.  This is good, but I wonder if maybe we should draw
> further inspiration from function arguments and also add parameter labels
> for generic arguments.  Both feel like low hanging fruit in the generics
> area (correct me if I’m wrong about that) and it would be great to see both
> enhancements make it into Swift 4.
>
> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Everyone,
>
> I've opened a PR (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.
>
> It would be great to hear your opinions and suggestions so I can refine
> the proposal.
>
>
> ___
> 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
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Xiaodi Wu via swift-evolution]

While it looks nicer without the angle brackets, that suggestion is
unresponsive to David's point that we need some way to distinguish
defaulted generic arguments from inferred generic arguments.

Consider:
```
let a: Optional = 1 // Optional

enum FloatPreferringOptional {
  case some(T)
  case none
}

let b: FloatPreferringOptional = 1
// Does this give you an FloatPreferringOptional?
```

If the answer to the above question is "yes, T is inferred as Int" then we
need some way to express "give me the default for T, which is Float." If
the answer to the above question is "no" then we need some way to express
"don't give me the default; rather, infer type T from the right hand side."


On Mon, Jan 23, 2017 at 6:30 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> This proposal looks good to me.  I have been looking forward to more
> flexible generic arguments for a while.
>
> I agree with previous commenters who prefer the option to leave off the
> angle brackets when all parameters have defaults.
>
> The proposal specifically mentions that the syntax is inspired by that of
> function arguments.  This is good, but I wonder if maybe we should draw
> further inspiration from function arguments and also add parameter labels
> for generic arguments.  Both feel like low hanging fruit in the generics
> area (correct me if I’m wrong about that) and it would be great to see both
> enhancements make it into Swift 4.
>
> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Everyone,
>
> I've opened a PR (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.
>
> It would be great to hear your opinions and suggestions so I can refine
> the proposal.
> ___
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Matthew Johnson via swift-evolution]

This proposal looks good to me.  I have been looking forward to more flexible 
generic arguments for a while.

I agree with previous commenters who prefer the option to leave off the angle 
brackets when all parameters have defaults.

The proposal specifically mentions that the syntax is inspired by that of 
function arguments.  This is good, but I wonder if maybe we should draw further 
inspiration from function arguments and also add parameter labels for generic 
arguments.  Both feel like low hanging fruit in the generics area (correct me 
if I’m wrong about that) and it would be great to see both enhancements make it 
into Swift 4.

> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution 
>  wrote:
> 
> Hi Everyone,
> 
> I've opened a PR (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.
> 
> It would be great to hear your opinions and suggestions so I can refine the 
> proposal.
> ___
> 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

Re: [swift-evolution] Default Generic Arguments

[T.J. Usiyan via swift-evolution]

A `Parser where StringType :
ParsableStringType`

`Void` is a fine default (somewhat questionable but follow me) because
`Void?` ends up having the same info as a boolean which means that our
Parser is, effectively, a recognizer. Thinking about it,
`GrammarRecognizer where StringType :
ParsableStringType` sidesteps the issue entirely and gives a second example
of when we could fill all type parameters.

On Mon, Jan 23, 2017 at 4:32 PM, David Waite 
wrote:

> You do have empty angle brackets today, which indicate an inferred generic
> argument rather than a defaulted generic argument. See:
>
>   1> let a = 1
> a: Int = 1
>   2> let b:Optional = a
> b: Int? = 1
>
> If Swift had defined Optional as Optional, statement 2
> would be ambiguous.
>
> I have a hard time coming up with a realistic generic which can have every
> argument defaulted. If someone can’t give a real-world example, I would
> require empty angle brackets just to differentiate defaulted vs inferred
> arguments.
>
> -DW
>
> On Jan 23, 2017, at 12:25 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am against requiring empty angle brackets. I could live with it either
> way, but I think that one reason to provide default types is to hide the
> detail that there is a type parameter until such a time as it is needed.
> Empty angle brackets call attention to the feature in a manner that
> discards any possible gains on this front. Empty angle brackets would be
> confusing to explain to someone new to the language and–more
> importantly–shouldn't be necessary to explain in the "falling back to
> defaults" case.
>
> On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> 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, X, etc.).
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Thomas Visser via swift-evolution]

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()
let two: X = X()
let three: X = 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 
>  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, X, etc.).
> 
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution 
> > wrote:
> 
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution 
>>> > wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> I've opened a PR (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 { }
>> 
>>  func f1() -> X { return X() }
>> 
>>  func f2() -> X { return X() }
>>  func f2() -> X { return X() }
>> 
>>  func f3(_: T) -> X { return X() }
>> 
>>  let x1: X = f1()   // okay: x1 has type X?
>>  let x2: X = f2()   // ambiguous?
>>  let x3a: X = f3(1.5)   // okay: x3a has type X?
>>  let x3b: X = f3(1)   // okay: x3a has type X?
>> 
>> 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
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> 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

Re: [swift-evolution] Default Generic Arguments

[David Waite via swift-evolution]

You do have empty angle brackets today, which indicate an inferred generic 
argument rather than a defaulted generic argument. See:

  1> let a = 1
a: Int = 1
  2> let b:Optional = a
b: Int? = 1

If Swift had defined Optional as Optional, statement 2 would be 
ambiguous.

I have a hard time coming up with a realistic generic which can have every 
argument defaulted. If someone can’t give a real-world example, I would require 
empty angle brackets just to differentiate defaulted vs inferred arguments.

-DW

> On Jan 23, 2017, at 12:25 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> I am against requiring empty angle brackets. I could live with it either way, 
> but I think that one reason to provide default types is to hide the detail 
> that there is a type parameter until such a time as it is needed.  Empty 
> angle brackets call attention to the feature in a manner that discards any 
> possible gains on this front. Empty angle brackets would be confusing to 
> explain to someone new to the language and–more importantly–shouldn't be 
> necessary to explain in the "falling back to defaults" case.
> 
> On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution 
> > 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, X, etc.).
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

> On Jan 23, 2017, at 3:18 PM, Srđan Rašić via swift-evolution 
>  wrote:
> 
> 
> I think such cases would be extremely rare and one would have to be very 
> ignorant about the types he/she works with. Additionally, that syntax is 
> useful only for types with one generic argument. Say we have `Promise Error>` and declare property as `let p: Promise`. How would you convey 
> the information that there is a second argument that could be changed? 
> Keeping the comma would be very ugly :)

To elaborate on this, default arguments are also a powerful tool for 
introducing new generic parameters in a way that’s source compatible. 
(potentially ABI compatible? Haven’t thought out implications of that). For 
instance, if you have a collection type, and decide to expose the allocator as 
a type parameter, defaults give you a backwards compatible way to do that. 
Making developers annotate “I’m using defaults” throws that away. If you make 
this “only” a warning then you’re just making busywork for the 99% of 
developers who always wanted the default behaviour, and couldn’t care less that 
it’s now configurable.

This would also go against the massive precedent set by default function 
arguments, which never need to be acknowledged.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

@doug:

> struct X { }

> func f1() -> X { return X() }

> func f2() -> X { return X() }
> func f2() -> X { return X() }

> func f3(_: T) -> X { return X() }

> let x1: X = f1()   // okay: x1 has type X?

Agreed. When type is explicitly defined in the context, that type should
override the default type. In this example type is explicitly defined by
the return argument so we infer that type instead of using the default one.

> let x2: X = f2()   // ambiguous?

Uncertain. I might even lean to `X` because defining a property as
`let x1: X` would be considered the same as defining it as `let x1:
X`. In that case I would expect that the correct overload is inferable.

> let x3a: X = f3(1.5)   // okay: x3a has type X?
> let x3b: X = f3(1)   // okay: x3a has type X?

Agreed. These two are related to x1. Type is defined in the context (by
inferring it from the literal) so it overrides the default argument.

I like the parallel with the default behaviour of literals - “if you can’t
infer a particular type, fill in a default". We should aim for that.


On Mon, Jan 23, 2017 at 9:18 PM, Srđan Rašić  wrote:

> I too agree that empty angle brackets are redundant because the
> information they convey is not useful enough to justify the syntax clutter.
> I would value clean syntax in this case more than explicitness and I think
> that would go along with Swift's philosophy. I would compare this to
> Swift's type inference where one can omit type information that's already
> known to the compiler in order to increase readability.
>
> > For example, if you had a struct that used a T (defaulted to Int) for a
> field, and that field's range should become a Double in your use case, you
> know that there's something you can change to get that behavior, while just
> X might look like you'd need to create your own type.
>
> I think such cases would be extremely rare and one would have to be very
> ignorant about the types he/she works with. Additionally, that syntax is
> useful only for types with one generic argument. Say we have `Promise = Error>` and declare property as `let p: Promise`. How would you
> convey the information that there is a second argument that could be
> changed? Keeping the comma would be very ugly :)
>
>
>
> On Mon, Jan 23, 2017 at 8:51 PM, Sean Heber  wrote:
>
>> I agree. I don’t think empty angle brackets convey anything useful to the
>> reader.
>>
>> l8r
>> Sean
>>
>>
>> > On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I am against requiring empty angle brackets. I could live with it
>> either way, but I think that one reason to provide default types is to hide
>> the detail that there is a type parameter until such a time as it is
>> needed.  Empty angle brackets call attention to the feature in a manner
>> that discards any possible gains on this front. Empty angle brackets would
>> be confusing to explain to someone new to the language and–more
>> importantly–shouldn't be necessary to explain in the "falling back to
>> defaults" case.
>> >
>> > On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution <
>> swift-evolution@swift.org> 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, X, etc.).
>> >
>> > On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>
>> >>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>>
>> >>> Hi Everyone,
>> >>>
>> >>> I've opened a PR (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 { }
>> >>
>> >>  func f1() -> X { return X() }
>> >>
>> >>  func f2() -> X { return X() }
>> >>  func f2() -> X 

Re: [swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

I too agree that empty angle brackets are redundant because the information
they convey is not useful enough to justify the syntax clutter. I would
value clean syntax in this case more than explicitness and I think that
would go along with Swift's philosophy. I would compare this to Swift's
type inference where one can omit type information that's already known to
the compiler in order to increase readability.

> For example, if you had a struct that used a T (defaulted to Int) for a
field, and that field's range should become a Double in your use case, you
know that there's something you can change to get that behavior, while just
X might look like you'd need to create your own type.

I think such cases would be extremely rare and one would have to be very
ignorant about the types he/she works with. Additionally, that syntax is
useful only for types with one generic argument. Say we have `Promise` and declare property as `let p: Promise`. How would you
convey the information that there is a second argument that could be
changed? Keeping the comma would be very ugly :)



On Mon, Jan 23, 2017 at 8:51 PM, Sean Heber  wrote:

> I agree. I don’t think empty angle brackets convey anything useful to the
> reader.
>
> l8r
> Sean
>
>
> > On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I am against requiring empty angle brackets. I could live with it either
> way, but I think that one reason to provide default types is to hide the
> detail that there is a type parameter until such a time as it is needed.
> Empty angle brackets call attention to the feature in a manner that
> discards any possible gains on this front. Empty angle brackets would be
> confusing to explain to someone new to the language and–more
> importantly–shouldn't be necessary to explain in the "falling back to
> defaults" case.
> >
> > On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> 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, X, etc.).
> >
> > On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> Hi Everyone,
> >>>
> >>> I've opened a PR (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 { }
> >>
> >>  func f1() -> X { return X() }
> >>
> >>  func f2() -> X { return X() }
> >>  func f2() -> X { return X() }
> >>
> >>  func f3(_: T) -> X { return X() }
> >>
> >>  let x1: X = f1()   // okay: x1 has type X?
> >>  let x2: X = f2()   // ambiguous?
> >>  let x3a: X = f3(1.5)   // okay: x3a has type X?
> >>  let x3b: X = f3(1)   // okay: x3a has type X?
> >>
> >> 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 

Re: [swift-evolution] Default Generic Arguments

[Michael Ilseman via swift-evolution]

> On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution 
>  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.

What are the perceived benefits by making it explicit that you’re using a 
defaulted-or-inferred generic type? What important pieces of information would 
the presence of an explicit “<>” communicate to future readers/maintainers of 
the code?

> 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, X, etc.).
> 
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution 
> > wrote:
> 
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution 
>>> > wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> I've opened a PR (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 { }
>> 
>>  func f1() -> X { return X() }
>> 
>>  func f2() -> X { return X() }
>>  func f2() -> X { return X() }
>> 
>>  func f3(_: T) -> X { return X() }
>> 
>>  let x1: X = f1()   // okay: x1 has type X?
>>  let x2: X = f2()   // ambiguous?
>>  let x3a: X = f3(1.5)   // okay: x3a has type X?
>>  let x3b: X = f3(1)   // okay: x3a has type X?
>> 
>> 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
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> 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

Re: [swift-evolution] Default Generic Arguments

[Sean Heber via swift-evolution]

I agree. I don’t think empty angle brackets convey anything useful to the 
reader.

l8r
Sean


> On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> I am against requiring empty angle brackets. I could live with it either way, 
> but I think that one reason to provide default types is to hide the detail 
> that there is a type parameter until such a time as it is needed.  Empty 
> angle brackets call attention to the feature in a manner that discards any 
> possible gains on this front. Empty angle brackets would be confusing to 
> explain to someone new to the language and–more importantly–shouldn't be 
> necessary to explain in the "falling back to defaults" case.
> 
> On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution 
>  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, X, etc.).
> 
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> I've opened a PR (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 { }
>> 
>>  func f1() -> X { return X() }
>> 
>>  func f2() -> X { return X() }
>>  func f2() -> X { return X() }
>> 
>>  func f3(_: T) -> X { return X() }
>> 
>>  let x1: X = f1()   // okay: x1 has type X?
>>  let x2: X = f2()   // ambiguous?
>>  let x3a: X = f3(1.5)   // okay: x3a has type X?
>>  let x3b: X = f3(1)   // okay: x3a has type X?
>> 
>> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> 
> -- 
> Trent Nadeau
> 
> ___
> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Trent Nadeau via swift-evolution]

The fact that it has a default generic argument means that it has a "knob"
to turn based on changes in needs of the code. For example, if you had a
struct that used a T (defaulted to Int) for a field, and that field's range
should become a Double in your use case, you know that there's something
you can change to get that behavior, while just X might look like you'd
need to create your own type.

On Mon, Jan 23, 2017 at 2:41 PM, Michael Ilseman  wrote:

>
> On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> 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.
>
>
> What are the perceived benefits by making it explicit that you’re using a
> defaulted-or-inferred generic type? What important pieces of information
> would the presence of an explicit “<>” communicate to future
> readers/maintainers of the code?
>
> 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, X, etc.).
>
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi Everyone,
>>
>> I've opened a PR (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 { }
>>
>> func f1() -> X { return X() }
>>
>> func f2() -> X { return X() }
>> func f2() -> X { return X() }
>>
>> func f3(_: T) -> X { return X() }
>>
>> let x1: X = f1()   // okay: x1 has type X?
>> let x2: X = f2()   // ambiguous?
>> let x3a: X = f3(1.5)   // okay: x3a has type X?
>> let x3b: X = f3(1)   // okay: x3a has type X?
>>
>> 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
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[T.J. Usiyan via swift-evolution]

I am against requiring empty angle brackets. I could live with it either
way, but I think that one reason to provide default types is to hide the
detail that there is a type parameter until such a time as it is needed.
Empty angle brackets call attention to the feature in a manner that
discards any possible gains on this front. Empty angle brackets would be
confusing to explain to someone new to the language and–more
importantly–shouldn't be necessary to explain in the "falling back to
defaults" case.

On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution <
swift-evolution@swift.org> 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, X, etc.).
>
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi Everyone,
>>
>> I've opened a PR (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 { }
>>
>> func f1() -> X { return X() }
>>
>> func f2() -> X { return X() }
>> func f2() -> X { return X() }
>>
>> func f3(_: T) -> X { return X() }
>>
>> let x1: X = f1()   // okay: x1 has type X?
>> let x2: X = f2()   // ambiguous?
>> let x3a: X = f3(1.5)   // okay: x3a has type X?
>> let x3b: X = f3(1)   // okay: x3a has type X?
>>
>> 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
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
>
> ___
> 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

Re: [swift-evolution] Default Generic Arguments

[Trent Nadeau via swift-evolution]

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, X, etc.).

On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Everyone,
>
> I've opened a PR (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 { }
>
> func f1() -> X { return X() }
>
> func f2() -> X { return X() }
> func f2() -> X { return X() }
>
> func f3(_: T) -> X { return X() }
>
> let x1: X = f1()   // okay: x1 has type X?
> let x2: X = f2()   // ambiguous?
> let x3a: X = f3(1.5)   // okay: x3a has type X?
> let x3b: X = f3(1)   // okay: x3a has type X?
>
> 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Joe Groff via swift-evolution]

> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution 
>> > wrote:
>> 
>> Hi Everyone,
>> 
>> I've opened a PR (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 { }
> 
>   func f1() -> X { return X() }
> 
>   func f2() -> X { return X() }
>   func f2() -> X { return X() }
> 
>   func f3(_: T) -> X { return X() }
> 
>   let x1: X = f1()   // okay: x1 has type X?
>   let x2: X = f2()   // ambiguous?
>   let x3a: X = f3(1.5)   // okay: x3a has type X?
>   let x3b: X = f3(1)   // okay: x3a has type X?
> 
> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Douglas Gregor via swift-evolution]

> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution 
>  wrote:
> 
> Hi Everyone,
> 
> I've opened a PR (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 { }

func f1() -> X { return X() }

func f2() -> X { return X() }
func f2() -> X { return X() }

func f3(_: T) -> X { return X() }

let x1: X = f1()   // okay: x1 has type X?
let x2: X = f2()   // ambiguous?
let x3a: X = f3(1.5)   // okay: x3a has type X?
let x3b: X = f3(1)   // okay: x3a has type X?

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!

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Default Generic Arguments

[Srđan Rašić via swift-evolution]

Hi Everyone,

I've opened a PR (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.

It would be great to hear your opinions and suggestions so I can refine the
proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution