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

[Matthew Johnson]

> On Jun 3, 2016, at 4:05 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> I am not the only one who feels that way.  Quoting Brent:
>> 
>> "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.”
>> 
>> I agree with this.  That is the motivation for my suggestion.  I think it’s at least worth discussing as an alternative to magically allowing an external parameter label to be omitted.  Brent, what do you think of my suggestion?
> 
> I think it could be simpler:
> 
> 	public struct Literal<LiteralType> {
> 		public let value: LiteralType
> 		internal init(_value value: LiteralType)
> 	}
> 	
> 	public protocol IntegerLiteralConvertible {
> 		associatedtype IntegerLiteralType
> 		init(_ literal: Literal<IntegerLiteralType>)
> 	}
> 
> Only the standard library can create a Literal, which it would do by constructing the IntegerLiteralType with its magic builtin literal stuff and wrapping it. You still have your magic parameter aspect, but without any actual magic, just access control. 

I like this solution as well as Xiaodi’s `@literal` idea better than the idea I came up with.  I think I like `@literal` best because it feels more appropriate to restrict an attribute to a specific context (signatures for literal convertible initializers) than anything else.  We don’t want to allow this in any other signatures and no types are restricted in that way.  The solution I came up with has that problem as well as the `#literal` “value” that is also restricted unlike other compiler generated values.  

I think our decision should be based upon which syntactic construct feels least inconsistent with other similar syntactic constructs and therefore feels the least arbitrary.  Restricting the usage of a generic `Literal` type to literal convertible initializers feels a little bit less arbitrary than allowing the call site to omit a label, but it feels a little bit more arbitrary than introducing an attribute that has a very specialized context of applicability.

> 
> -- 
> Brent Royal-Gordon
> Architechies
>