[swift-evolution] Revisiting SE-0041 Names

[Matthew Johnson]

> 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.

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 <mailto:gribozavr at gmail.com>>>*/
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/74e70159/attachment.html>