[swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

[T.J. Usiyan]

+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 at swift.org> wrote:

> > On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon <brent at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/437d6ee9/attachment.html>