[swift-evolution] Revisiting SE-0041 Names

[Dave Abrahams]

on Mon Jun 27 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

>> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Wed Jun 22 2016, Matthew Johnson <swift-evolution at swift.org
>
>> <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko
>>>> <gribozavr at gmail.com <mailto:gribozavr at gmail.com>> wrote:
>>>> 
>>>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> 
>>>> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>
>>>> wrote:
>>>>> Proposal:
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>>> 
>>>>> Rejection: "The feedback on the proposal was generally positive about the
>>>>> idea of renaming these protocols, but the specific names in the proposal are
>>>>> not well received, and there is no apparent confluence in the community on
>>>>> better names.  The core team prefers discussion to continue -- if/when there
>>>>> is a strong proposal for a better naming approach, we can reconsider
>>>>> renaming these."
>>>>> 
>>>>> John McCall: "To be clear, I don't care about the name.  If you want to
>>>>> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
>>>>> the conversation into the muck again. :)  It's the design of the
>>>>> requirements that I'm pretty opposed to revisiting."
>>>>> 
>>>>> The Problem: This is really the last chance to rationalize this across the
>>>>> language and to evaluate whether other protocol groups should have a core
>>>>> scheme for naming.
>>>> 
>>>> Hi Erica,
>>>> 
>>>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
>>>> and me from the last time this was discussed.  Unfortunately I can't
>>>> find the exact email, so I can't provide a link.
>>>> 
>>>> - The "literal" protocols are not about conversion, they are about
>>>> adopting a certain syntax provided by the language.  "Convertible" in
>>>> the name is a red herring: a type can't be convertible from an integer
>>>> literal because there is no "IntegerLiteral" entity in the type
>>>> system.  The literal *becomes* typed as the corresponding literal type
>>>> (e.g., Int or String), and as far as the user at the call site is
>>>> concerned, there is no visible conversion (even if one is happening
>>>> behind the scenes).
>>>> 
>>>> Our suggestion was to focus on the "adopting the syntax" part.  We
>>>> suggested moving the "literal convertible" protocols into a
>>>> pseudo-namespace "Syntax".  It could be implemented like this:
>>>> 
>>>> protocol _IntegerLiteralSyntax {}
>>>> enum Syntax {
>>>> typealias IntegerLiteral = _IntegerLiteralSyntax
>>>> }
>>>> 
>>>> And used like this:
>>>> 
>>>> struct Int : Syntax.IntegerLiteral {}
>>> 
>>> I’m working on a draft of this proposal right now.  I have a couple questions.  
>>> 
>>> First, I’d like to list the standard library team as co-authors if you
>>> desire because this is really your idea.  Let me know what you would
>>> prefer.
>>> 
>>> Second, I wonder if it might make more sense to name the protocols
>>> `Syntax.IntegerLiteralInitializable`.  Dave has opposed
>>> `Initializable` as a general convention because it implies pure syntax
>>> and doesn’t carry any semantics.  But in this case the semantics *are*
>>> essentially the syntax.  Erica pointed out to me off list that at the
>>> usage site the `Syntax.IntegerLiteral` names could confuse somebody
>>> into thinking in terms of *isa* rather than *can do* (i.e. Int is an
>>> IntegerLiteral rather than Int can be *initialized* with an
>>> IntegerLiteral).
>> 
>> Really, this is exactly the sense in which we want it to be interpreted.
>> It is *not* a capability.  There is no such thing as an IntegerLiteral
>> instance from which one can initialize an Int.  There are only syntactic
>> integer literals, which, given the right type context, can be-a Int.
>> The intializer one gets from the protocol is merely the mechanism used
>> by the compiler to create this Int.
>
> That is a technically correct statement, but I think the model most
> programmers will have (good or bad) is of initializing with an integer
> literal.  I think this is evidenced to some degree by the feedback
> people are providing on the names.

Yes, that's a very strong reason not to name the protocols so as to
encourage that misinterpretation. :-)

> That said, I am trying to stay out of the fray of the bike shedding on
> this.  IMO the most important thing is to do *something* here as long
> as its reasonable and the solution suggested by the standard library
> team is definitely reasonable.  That is why I have written the
> proposal exactly as the standard library team suggested.  :)

Thank you.

-- 
-Dave