Re: [swift-evolution] Default Generic Arguments

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 =

Re: [swift-evolution] Default Generic Arguments

> 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 not

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

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"

Re: [swift-evolution] Default Generic Arguments

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 p

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

> 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

Re: [swift-evolution] Default Generic Arguments

> 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 rule

Re: [swift-evolution] Default Generic Arguments

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 inferen

Re: [swift-evolution] Default Generic Arguments

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 t

Re: [swift-evolution] Default Generic Arguments

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 tha

Re: [swift-evolution] Default Generic Arguments

> 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

Re: [swift-evolution] Default Generic Arguments

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 T

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

> 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

> 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

Re: [swift-evolution] Default Generic Arguments

> 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 IntegerLiteralCo

Re: [swift-evolution] Default Generic Arguments

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. No

Re: [swift-evolution] Default Generic Arguments

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 foo(t: T) { ... } foo(22) // ^ // | // What type gets inferred h

Re: [swift-evolution] Default Generic Arguments

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 ```

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

> 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: > ``` >

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

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 Foo, this should be a resilient change for

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

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 < > s

Re: [swift-evolution] Default Generic Arguments

> 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

Re: [swift-evolution] Default Generic Arguments

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-inte

Re: [swift-evolution] Default Generic Arguments

> 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 no

Re: [swift-evolution] Default Generic Arguments

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 no

Re: [swift-evolution] Default Generic Arguments

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 b

Re: [swift-evolution] Default Generic Arguments

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 : ParsableStri

Re: [swift-evolution] Default Generic Arguments

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:

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

> 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 `Pr

Re: [swift-evolution] Default Generic Arguments

@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

Re: [swift-evolution] Default Generic Arguments

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 in

Re: [swift-evolution] Default Generic Arguments

> 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 a

Re: [swift-evolution] Default Generic Arguments

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 defau

Re: [swift-evolution] Default Generic Arguments

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 yo

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

> 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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Everyone, >> >> I've opened a PR (https://github.com/apple/swift-evolution/pull/591 >>

Re: [swift-evolution] Default Generic Arguments

> 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 t

[swift-evolution] Default Generic Arguments

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 cove