On Fri, Jun 16, 2017 at 12:17 AM, David Hart <[email protected]> wrote:
> > > On 16 Jun 2017, at 01:55, Xiaodi Wu <[email protected]> wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart <[email protected]> wrote: > >> On 16 Jun 2017, at 00:41, David Hart <[email protected]> wrote: >> >> >> On 15 Jun 2017, at 19:28, Chris Lattner <[email protected]> wrote: >> >> >> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution < >> [email protected]> o >> >> > >>>> > let (a : Int, b : Float) = foo() >>>> >>>> >>>> I think it would be better if the compiler raised a warning whenever >>>> you tried to redefine a builtin type. >>> >>> >>> That’s essentially my preferred solution as well, as it gets to the root >>> of the confusion. >>> >>> Naming a variable the same as a type should be similar to naming a >>> variable the same as a reserved keyword and require backticks. (A previous >>> suggestion to enforce capitalization falls down with full Unicode support >>> and complicates interop where imported C structures might be lowercase and >>> constants might be all caps.) No need to treat built-in types specially; >>> it’s equally a problem with types imported from other libraries, which can >>> be shadowed freely today. For full source compatibility this can be a >>> warning instead of an error–should be sufficient as long as it’s brought to >>> the user’s attention. In fact, probably most appropriate as a warning, >>> since the _compiler_ knows exactly what’s going on, it’s the human that >>> might be confused. >>> >>> >>> I kind of agree with all you say. But I also feel that tuple element >>> names in patterns are very rarely used and not worth the added complexity >>> and confusing. Going back to the old: “Would be add it to Swift if it did >>> not exist?”, I would say no. >>> >> >> That was the standard for removing features before Swift 3, but with >> source compatibility the bar is now much higher. >> >> >> Completely agreed. My belief on this is that it is a legacy Swift 1 type >> system capability that no one uses. I have no data to show that though. >> >> Is the feature harmful? >> >> >> Yes, absolutely. The shadowing isn't the thing that bothers me, it is >> that swift has a meaning for that very syntax in other contexts, and that >> this is completely different meaning. People absolutely would get confused >> by this if they encountered it in real code that they themselves didn't >> write, and I'm not aware of any good (non theoretical) use for it. >> >> My point is, not on its own it isn’t: warning on variables shadowing >> types is sufficient to resolve the problems shown here. >> >> >> Again, my concern is that this is a confusing and misleading feature >> which complicates and potentially prevents composing other features in the >> future. >> >> >> >> How strange that we’re talking about this issue in a thread about >> SE-0110. >> >> >> This came up in the discussion about 110 because we were exploring >> whether it was plausible to expand the function parameter grammar to >> support destructuring in the position where a name goes. There are many >> concerns about whether this is a good idea, but he existence of this in the >> tuple destructuring pattern grammar is pretty much a showstopper. >> >> If anything, the response to that proposal should be a cautionary tale >> that users can take poorly to removing features, sometimes in unanticipated >> ways. >> >> >> Agreed, it may be too late to correct this (certainly we can't outright >> remove it in Swift 4 if someone is using it for something important). >> However if it turns out that it really isn't used, then warning about it in >> 4 and removing it shortly after may be possible. >> >> >> And I think its difficult to make the parallel between the two. SE-0110 >> basically impacted everybody calling higher-order functions on Dictionary >> (+ more users from libraries like RxSwift), which makes an enormous >> proportion of the Swift community. On the other hand, despite the enormous >> amount of time I have sinked into learning, discussing and enjoying Swift, >> I never come upon the tuple element name syntax in patterns until Robert >> pointed to it out on twitter several weeks ago. >> >> >> By the way, I’m not attempting to deduce that nobody uses this feature by >> the fact I didn’t know about it. But I think it’s one interesting datapoint >> when comparing it to SE-0110. >> > > > SE-0110, **in retrospect**, has had impacts on a lot of users; > prospectively, it was thought to be a minor change, even after review and > acceptance. > > Keep in mind that this proposed change would also eliminate inline tuple > shuffle. For instance, the following code will cease to compile: > > let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5) > func f(color: (r: Double, g: Double, b: Double, a: Double)) { > print(color) > } > f(color: x) > > It is an open question how frequently this is used. But like implicit > tuple destructuring, it currently Just Works(TM) and users may not realize > they’re making use of the feature until it’s gone. > > > Xiaodi, can you explain to me what makes you think that your example piece > of code would be concerned by Chris' suggestion to remove tuple element > names from the pattern grammar? That's not what I understood. > This issue was discussed in a thread beginning May 4 titled "Remove tuple shuffles" started by Robert Widmann. For a fuller exposition I recommend reading that (very long) thread. From his text: """ A tuple-shuffle is an undocumented feature of Swift in which one can re-order the indices of a tuple by writing a pattern that describes a permutation in a syntax reminiscent of adding type-annotations to a parameter list: let a = (x: 1, y: 2) var b: (y: Int, x: Int) b = a It can be used to simultaneously destructure and reorder a tuple: let tuple = (first: 0, second: (x: 1, y: 2)) let (second: (x: b, y: c), first: a) = tuple It can also be used to map parameter labels out of order in a call expression: func foo(_ : (x : Int, y : Int)) {} foo((y: 5, x: 10)) // Valid """ All of these examples demonstrate one and the same feature, which is the one that Chris is calling dubious; the pattern-matching syntax being mentioned here exists to enable this feature, and the proposal would be to rip it all out. >> -Chris >> >> >> `let (a : Int, b : Float) = foo()` is confusing but if you were to use >>>> your own type (e.g., `struct S {}` and replace Int and Float with S) you >>>> would get a compiler error. If the compiler warned you that you were >>>> reassigning Int and Float, you’d probably avoid that problem. Or, for a >>>> more extreme fix, we could make reassigning builtin types illegal since >>>> there is pretty much no valid reason to do that. >>>> >>>> >>>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution < >>>> [email protected]> wrote: >>>> > >>>> > >>>> > >>>> > Sent from my iPad >>>> > >>>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution < >>>> [email protected]> wrote: >>>> >> >>>> >> >>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <[email protected]> >>>> wrote: >>>> >>> >>>> >>> What’s the status of this Chris’s double parens idea below? It >>>> garnered some positive responses, but the discussion seems to have fizzled >>>> out. Is there something needed to help nudge this along? >>>> >>> >>>> >>> What’s the likelihood of getting this fixed before Swift 4 goes >>>> live, and the great wave of readability regressions hits? >>>> >> >>>> >> We discussed this in the core team meeting today. Consensus seems >>>> to be that a change needs to be made to regain syntactic convenience here. >>>> Discussion was leaning towards allowing (at least) the parenthesized form, >>>> but more discussion is needed. >>>> >> >>>> >> >>>> >> One (tangential) thing that came up is that tuple element names in >>>> tuple *patterns* should probably be deprecated and removed at some point. >>>> Without looking, what variables does this declare?: >>>> >> >>>> >> let (a : Int, b : Float) = foo() >>>> > >>>> > Another option would be to require let to appear next to each name >>>> binding instead of allowing a single let for the whole pattern. I >>>> personally find that much more clear despite it being a little bit more >>>> verbose. >>>> > >>>> >> >>>> >> ? >>>> >> >>>> >> -Chris >>>> >> >>>> >> _______________________________________________ >>>> >> swift-evolution mailing list >>>> >> [email protected] >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > [email protected] >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
