[swift-evolution] Revisiting SE-0041 Names

[L. Mihalkovic]

Regards
LM
(From mobile)

> On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> 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> wrote:
>> 
>>>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko
>>>> <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>>
>>>> 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.

Perpetuating the wrong idea does not make it a good idea... There was Ptolemy and then there was Galileo.

> 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.  :)  
> 
>> 
>>> 
>>> Please let me know if this name change would be acceptable to the
>>> standard library team or may be met with resistance.  I want this
>>> proposal to be acceptable to the team from the start.
>>> 
>>> Matthew
>>> 
>>>> 
>>>> - For protocols that are representing conversions between types that
>>>> actually exist in the library, there is not enough precedent yet to
>>>> make a general conclusion and standardize a pattern.
>>>> 
>>>> Dmitri
>>>> 
>>>> -- 
>>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko
>>>> <gribozavr at gmail.com
>>>> <mailto:gribozavr at gmail.com>>*/
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/8096e7e2/attachment.html>