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

[John McCall]

> On Jun 3, 2016, at 5:13 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> On Jun 3, 2016, at 6:23 PM, John McCall <rjmccall at apple.com> wrote:
> 
>>>> On Jun 3, 2016, at 4:07 PM, David Sweeris <davesweeris at mac.com> wrote:
>>>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Using an external parameter label in a declaration and allowing it to be omitted at the call site does not feel like the right answer to me.  I think we can find a better way to present this syntactically.
>>> 
>>> +eleventy gajillion
>> 
>> I'm actually quite happy with the user-facing aspects of the current literal protocols and see zero reason to update them for this, so if that's the choice, I'll just leave this aside.
> 
> Are you suggesting that preserving the current syntax of the literal protocols is more important than fixing this behavior so it works like most people seem to expect?  Why not be open to other syntactic solutions? 

I think fixing the behavior is good, and I stand by this proposal.  There is, however, nothing glaringly wrong with the literal protocols.  They do not need to redesigned simply because we found a syntactic interaction that needs to be cleaned up.

There are good reasons the protocols have evolved the way they have.  The labels clearly mark the purpose of each initializer and distinguish one from another on types that support multiple literal kinds.  The labels also clearly indicate that the initializers are not intended for general use.  The argument(s) to the initializer do not always represent a single value of literal type.  Some protocols provide multiple initializers, and it is quite possible that that will become gradually more common as we explore ways to grant more flexibility to code outside of the standard library.  And we actually consider it good that you can invoke these initializers explicitly; it's only accidental use that we feel it's important to avoid, which labels provide excellent protection against.

If you have specific criticisms of any of the literal protocols, e.g. you find them limiting or non-performant for your own types, then you are welcome to raise them here.  However, resemblance to actual literal syntax has never been a design goal for the literal protocols; and besides, this will always be a secondary literal syntax, one far less important than contextual typing.

John.