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

[Brent Royal-Gordon]

> 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