[swift-evolution] Revisiting SE-0041 Names

[Dave Abrahams]

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.

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