> On Jun 3, 2016, at 4:05 PM, Brent Royal-Gordon <br...@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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
