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

[Xiaodi Wu]

The IntegerLiteral type idea might be worth exploring. It does seem to
provide some additional consistency. For example, wasn't it clarified on
this list just recently that literals don't have a type and adopt one based
on context? It'd be nice to point out that 42 is an IntegerLiteral when
explaining that it's not an Int.

On Thu, Jun 2, 2016 at 18:22 Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > 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? :)
>
> I think the difference between a cast (which merely reinterprets a value
> as a compatible type) and a fullwidth conversion (which creates a similar
> instance of an incompatible type) is very important to understanding how to
> write Swift, and we shouldn't muddy the waters by creating a magic syntax.
>
> > 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.
>
> If you're planning to change `IntegerLiteralConvertible` and friends to
> require a fullwidth conversion initializer like `init(_ value:
> IntegerLiteralType)`, then this is simply an overload resolution rule. In
> that case, I think your proposal is fine.
>
> But if you're going to call `init(integerLiteral:)` like it's `init(_:)`,
> I don't think that's a good idea. Parameter labels are supposed to be
> significant; we don't want to lose that.
>
> --
> 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/d6345324/attachment.html>