<div dir="ltr">+1<div>It has nagged at me that this can happen even though I understood *why* it happens.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 6:22 PM, John McCall via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
>> 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.<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span class=""><br>
> 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.<br>
<br>
</span>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? :)<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
John.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> 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.)<br>
><br>
> UInt16(42)<br>
> ^~~~~~ ^~<br>
> Use of initializer with integer literal does not cast '42' to 'UInt16'<br>
> Fix-It: Replace with '42 as UInt16'<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>