[swift-evolution] Revisiting SE-0041 Names

[Dmitri Gribenko]

On Wed, Jun 22, 2016 at 7:42 PM, Matthew Johnson <matthew at anandabits.com> 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> 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.

Thank you.  I don't mind either way.

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

IIRC the consensus that Dave, Max and I reached was
`Syntax.IntegerLiteral`, but this does not represent the opinion of
the core team.  (We did not talk to the whole team, just the three of
us.)

I think the possibility of confusion is very small because users will
not refer to the protocol as 'IntegerLiteral', it will be qualified as
'Syntax.IntegerLiteral'.

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