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

[John McCall]

> On Jun 2, 2016, at 4:22 PM, Brent Royal-Gordon <brent at architechies.com> 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.

My point is that a literal doesn't really have a pre-existing type.  Your explanation relies on a very strange model in which we assign it an arbitrary type just so we can introduce unwanted semantic conversions from that type.

>> 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.

This does not work.  Literal construction is not necessarily as simple as converting from an existing type, and it's important to use a semantically distinguished initializer.

> 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.

It sounds like you're not in favor of the proposal, then.

John.