+1 It has nagged at me that this can happen even though I understood *why* it happens.
On Thu, Jun 2, 2016 at 6:22 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> In my opinion, using this initializer-call syntax to build an > explicitly-typed literal is an obvious and natural choice with several > advantages over the "as" syntax. However, even if you disagree, it's clear > that programmers are going to continue to independently try to use it, so > it's really unfortunate for it to be subtly wrong. > > > > I've seen developers do this; in one memorable case, it resulted in > Swift taking a ridiculously long time to typecheck an expression, since the > seemingly pinned-down types of the literals had actually become *more* > ambiguous, not less. > > Yes, this would also tend to improve compile times, since currently we end > up generating a massively-ambiguous constraint system which must be > resolved by type defaulting. That's not really why I'm proposing this, > though. > > > However, it's not difficult to teach developers to use `as`. Usually > what's happening is that their mental model of the language is wrong: they > think of `UInt16(foo)` as a cast to a primitive type, and are surprised to > learn that it's actually an initializer on a struct and they're > initializing an instance. Learning this helps them understand how the > language works, what the difference is between initializers and `as`, and > how they can write the same things they see in the standard library types. > > So, you think that this syntax is enticing to new developers who naturally > think that the feature works the way that I'm proposing it should work, and > you think that the right solution is to make the syntax illegal so that you > can more conveniently tell them it doesn't work that way? :) > > You can still tell them that it's a struct and you're calling an > initializer on it; it's just that the initializer chosen is the special > literal initializer because the argument is a literal. > > John. > > > > > > > I think *actually* turning this into magic would be counterproductive. > The better solution is to make the compiler replace me in that story, by > having it emit a warning with a fix-it. It keeps initializer calls meaning > exactly what they say. (And it doesn't require an evolution proposal to do, > since you can add a warning with a mere bug.) > > > > UInt16(42) > > ^~~~~~ ^~ > > Use of initializer with integer literal does not cast '42' to > 'UInt16' > > Fix-It: Replace with '42 as UInt16' > > > > -- > > Brent Royal-Gordon > > Architechies > > > > _______________________________________________ > 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
