Revisiting SE-0041 Names

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.

···

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@swift.org> wrote:
on Wed Jun 22 2016, Matthew Johnson <swift-evolution@swift.org > >> <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >>>> <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:
On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> >>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> >>>> wrote:

--
-Dave

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.

Starting with this:

    "Conforming to a protocol is supposed to be a strong declaration
about not just syntax, but semantics" - D. Abrahams

There's an exception to everything. In this case, protocols used to
interface with the language at the lowest levels may be purely about
syntax.

Current:

  /// Conforming types can be initialized with integer literals.
  public protocol IntegerLiteralConvertible {

      associatedtype IntegerLiteralType

      /// Create an instance initialized to `value`.
      public init(integerLiteral value: Self.IntegerLiteralType)
  }

Maybe my issue is that this should really read:

  /// Conforming types accept integer literal syntax for initialization
  /// allowing types to use integer literals in statements
  ///
  /// ```
  /// let instance: T = *integer literal*
  /// ```
  ///
  /// for example:
  ///
  /// ```
  /// let myDouble: Double = 2 // The literal 2 is automatically
cast
  /// let anotherDouble: Double = myDouble * 5 // The literal 5
is automatically cast
  /// ```
  public protocol Syntax.SupportsIntegerLiteralValues {

            /// For constrained integer literal types, which otherwise
default to `Int`.
      associatedtype IntegerLiteralType = Int

             /// Create an instance initialized to `value`.
      /// Required to enable in-line syntactic substitutions
      public init(integerLiteral value: Self.IntegerLiteralType)

  }

So a protocol of `Syntax.AcceptsIntegerLiteralValues` or
`Syntax.AutoconvertsIntegerLiteralValues` might
better explain what this is doing and the intent of the protocol. It
ain't short but it's a hella lot clearer.

Being clear isn't helpful when it clearly implies the wrong meaning.
What's essential about this protocol neither that it “accepts” nor that
it “autoconverts” anything. It's that it allows allows an integer
literal to be interpreted as an expression having the conforming type,
or to put it differently, it confers integer literal syntax upon the
conforming type.

···

on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 27, 2016, at 8:29 AM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote:

--
Dave

Regards
LM
(From mobile)

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.

···

On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 22 2016, Matthew Johnson <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >>>> <gribozavr@gmail.com> wrote:
On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org >>> >>>> <mailto:swift-evolution@swift.org>> >>>> wrote:

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@gmail.com
<mailto:gribozavr@gmail.com>>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The point of using "Syntax" is to emphasize that this protocol is for
integration with the language syntax. The "Syntax" pseudo-namespace
groups protocols that provide a special kind of a capability --
changing the meaning of builtin language syntax. This protocol is not
meant to be coded against, used in other APIs or handled by the code
in any other way except by being adopted (except maybe in the standard
library code itself).

Should we add any other compiler interfaces that affect how builtin
syntax works, they would also go into the "Syntax" namespace.

Dmitri

···

On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote:

> On Jun 22, 2016, at 19:35, Dmitri Gribenko <gribozavr@gmail.com> wrote:
>
>> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris@mac.com> >> >> wrote:
>> That's a really interesting idea. Is "Syntax" a placeholder, or is that
>> the intended name?
>
> It is the best name we could come up with, we are open to better
> suggestions.

I guess it depends on the intended semantics of the "namespace". If the
purpose is to be a container for the various LiteralConvertible protocols,
then maybe something like `AcceptsLiteralType.Integer` might be better? It's
a bit wordy, though.

I get what's being aimed at here, but I think the meaning of `Syntax` in
this context is indecipherable. IIUC, the point to be conveyed by the term
is that a literal has no type until it is supplied as an argument to the
initializer and becomes typed.

--
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@gmail.com>*/

>>
>>
>> >
>> >> That's a really interesting idea. Is "Syntax" a placeholder, or is
that
>> >> the intended name?
>> >
>> > It is the best name we could come up with, we are open to better
>> > suggestions.
>>
>> I guess it depends on the intended semantics of the "namespace". If the
>> purpose is to be a container for the various LiteralConvertible
protocols,
>> then maybe something like `AcceptsLiteralType.Integer` might be better?
It's
>> a bit wordy, though.
>
>
> I get what's being aimed at here, but I think the meaning of `Syntax` in
> this context is indecipherable. IIUC, the point to be conveyed by the
term
> is that a literal has no type until it is supplied as an argument to the
> initializer and becomes typed.

The point of using "Syntax" is to emphasize that this protocol is for
integration with the language syntax. The "Syntax" pseudo-namespace
groups protocols that provide a special kind of a capability --
changing the meaning of builtin language syntax. This protocol is not
meant to be coded against, used in other APIs or handled by the code
in any other way except by being adopted (except maybe in the standard
library code itself).

This makes a lot of sense now after your expanded explanation. I still
think, though, that the name reads rather absurdly. Most charitably, your
types would conform to "integer literal syntax," whatever that means.
Visually, it looks like your types "conform to Syntax." Could I suggest
maybe `SyntacticIntegration` or `SyntaxIntegrating`? Something along those
lines.

Should we add any other compiler interfaces that affect how builtin

···

On Thu, Jun 23, 2016 at 4:34 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution > > <swift-evolution@swift.org> wrote:
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko <gribozavr@gmail.com> > wrote:
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris@mac.com> > >> >> wrote:
syntax works, they would also go into the "Syntax" namespace.

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@gmail.com>*/

I suppose "Syntax.AllowsIntegerLiteralToBeInterpretedAsExpressionOfConformingType"
is a tiny bit too wordy?

Putting on my hat of extreme pedantry:

Conformance does "accept" integer literals. By conforming, this protocol
allows them to be interpreted as expressions of the conforming type. That
reads as acceptance to me.

I'm not sure if you could call this promotion, casting, interpretation or whatever
but the way you describe it sounds exactly backwards from the way it's used.

You say "It confers integer literal syntax", which reads to me as "Oh great, I can
use a floating point number as an integer literal. Great, let x: Int = 4.2".

When I see it used, I think "Conforming types consume integer literal syntax as native",
which is more `let x: Double = 1` and `let y Double = 2.5 * myOtherDouble * 4`.

And then grabbing a paintbrush of many colors, perhaps "Syntax.IntegerLiteralConsumer"?

-- E

···

On Jun 27, 2016, at 12:13 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

So a protocol of `Syntax.AcceptsIntegerLiteralValues` or
`Syntax.AutoconvertsIntegerLiteralValues` might
better explain what this is doing and the intent of the protocol. It
ain't short but it's a hella lot clearer.

Being clear isn't helpful when it clearly implies the wrong meaning.
What's essential about this protocol neither that it “accepts” nor that
it “autoconverts” anything. It's that it allows allows an integer
literal to be interpreted as an expression having the conforming type,
or to put it differently, it confers integer literal syntax upon the
conforming type.

>
>> That's a really interesting idea. Is "Syntax" a placeholder, or is that
the intended name?
>
> It is the best name we could come up with, we are open to better
suggestions.

I guess it depends on the intended semantics of the "namespace". If the
purpose is to be a container for the various LiteralConvertible protocols,
then maybe something like `AcceptsLiteralType.Integer` might be better?
It's a bit wordy, though.

I get what's being aimed at here, but I think the meaning of `Syntax` in
this context is indecipherable. IIUC, the point to be conveyed by the term
is that a literal has no type until it is supplied as an argument to the
initializer and becomes typed.

No, it has no type until its type is deduced. No initializer call
appears in the source. Supplying the argument to the initializer is
merely the mechanism by which the compiler constructs the value once the
type is deduced.

Maybe we could say that the type gives form to the literal or embodies
the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

   IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

···

on Thu Jun 23 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jun 22, 2016, at 19:35, Dmitri Gribenko <gribozavr@gmail.com> wrote:
>> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris@mac.com> >> wrote:

>> Also, why an enum? Especially one without any cases...
>
> It is not possible to create an instance of an enum that does not have
> cases. It becomes essentially a namespace.

Oh that's a clever work-around. I like it :-)

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

Should we use a different word to declare such protocols?
syntax IntegerLiteral { // where “syntax” is just the lowercase spelling of whatever we end up calling the namespace
    // everything from `IntegerLiteralConvertible` goes here
}

It would certainly help create the mental distinction between these “syntactic” protocols and "normal” protocols.

- Dave Sweeris

···

On Jun 27, 2016, at 13:13, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

There's an exception to everything. In this case, protocols used to
interface with the language at the lowest levels may be purely about
syntax.

>>
>>
>> >
>> >> That's a really interesting idea. Is "Syntax" a placeholder, or is
that
>> >> the intended name?
>> >
>> > It is the best name we could come up with, we are open to better
>> > suggestions.
>>
>> I guess it depends on the intended semantics of the "namespace". If the
>> purpose is to be a container for the various LiteralConvertible
protocols,
>> then maybe something like `AcceptsLiteralType.Integer` might be better?
It's
>> a bit wordy, though.
>
>
> I get what's being aimed at here, but I think the meaning of
> `Syntax` in this context is indecipherable. IIUC, the point to be
> conveyed by the term is that a literal has no type until it is
> supplied as an argument to the initializer and becomes typed.

The point of using "Syntax" is to emphasize that this protocol is for
integration with the language syntax. The "Syntax" pseudo-namespace
groups protocols that provide a special kind of a capability --
changing the meaning of builtin language syntax. This protocol is not
meant to be coded against, used in other APIs or handled by the code
in any other way except by being adopted (except maybe in the standard
library code itself).

This makes a lot of sense now after your expanded explanation. I still
think, though, that the name reads rather absurdly. Most charitably, your
types would conform to "integer literal syntax," whatever that means.
Visually, it looks like your types "conform to Syntax."

I dunno, this kind of construct is precedented. Nobody thinks

    class MyDelegate : Foundation.SomeDelegate { ... }

makes it look like MyController conforms to Foundation.

Could I suggest maybe `SyntacticIntegration` or `SyntaxIntegrating`?
Something along those lines.

Doesn't that just use complex words where a simpler one would do? I
don't understand how that helps.

···

on Thu Jun 23 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Thu, Jun 23, 2016 at 4:34 AM, Dmitri Gribenko > <gribozavr@gmail.com> > wrote:

On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu >> <xiaodi.wu@gmail.com> wrote:
> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution >> > <swift-evolution@swift.org> wrote:
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko >> >> > <gribozavr@gmail.com> >> wrote:
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris >> >> >> <davesweeris@mac.com> >> >> >> wrote:

--
-Dave

There's an exception to everything. In this case, protocols used to
interface with the language at the lowest levels may be purely about
syntax.

Should we use a different word to declare such protocols?

I don't think so.

syntax IntegerLiteral { // where “syntax” is just the lowercase
spelling of whatever we end up calling the namespace
    // everything from `IntegerLiteralConvertible` goes here
}

It would certainly help create the mental distinction between these
“syntactic” protocols and "normal” protocols.

I doubt this distinction is worth the language complexity. Expressing
it in the library via the “Syntax.” qualification does the same thing
without any compiler changes.

···

on Mon Jun 27 2016, David Sweeris <davesweeris-AT-mac.com> wrote:

On Jun 27, 2016, at 13:13, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

--
Dave

You didn't respond to my earlier suggestion so I'd like to pitch it again.

What about "Syntax.IntegerLiteralConsumer", which suggests that
conforming types can consume integer literal syntax as native to their
type.

-- E

···

On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Maybe we could say that the type gives form to the literal or embodies
the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

  IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

>
>>
>> >
>> >> That's a really interesting idea. Is "Syntax" a placeholder, or is
that
>> the intended name?
>> >
>> > It is the best name we could come up with, we are open to better
>> suggestions.
>>
>> I guess it depends on the intended semantics of the "namespace". If the
>> purpose is to be a container for the various LiteralConvertible
protocols,
>> then maybe something like `AcceptsLiteralType.Integer` might be better?
>> It's a bit wordy, though.
>>
>
> I get what's being aimed at here, but I think the meaning of `Syntax` in
> this context is indecipherable. IIUC, the point to be conveyed by the
term
> is that a literal has no type until it is supplied as an argument to the
> initializer and becomes typed.

No, it has no type until its type is deduced. No initializer call
appears in the source. Supplying the argument to the initializer is
merely the mechanism by which the compiler constructs the value once the
type is deduced.

Right. Sorry, clearly a brainfart there on my part.

> Maybe we could say that the type gives form to the literal or embodies
> the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
> `IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being
anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

   IntegerLiteralExpressible

I think that sounds wonderful.

I *think* I still would want to sink this name into the Syntax
namespace, though.

`Syntax.IntegerLiteralExpressible` absolutely makes sense to me. To me,
this says, the conforming type is integer literal expressible, which falls
under the umbrella of syntax. Somehow, `Syntax.IntegerLiteral` just does
not compute in my head, maybe because instinctively it looks like something
should come after "literal," and using "syntax" to plug that hole doesn't
yield an interpretable name.

···

On Mon, Jun 27, 2016 at 6:47 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Thu Jun 23 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:
> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > > swift-evolution@swift.org> wrote:
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko <gribozavr@gmail.com> > wrote:
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris@mac.com> > >> wrote:

>> >> Also, why an enum? Especially one without any cases...
>> >
>> > It is not possible to create an instance of an enum that does not have
>> > cases. It becomes essentially a namespace.
>>
>> Oh that's a clever work-around. I like it :-)
>>
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

To me, the idea of a type (other than, say, a parser) consuming syntax
is pretty alien. So this one is sorta esoteric too, IMO.

···

on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Maybe we could say that the type gives form to the literal or embodies
the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

  IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

You didn't respond to my earlier suggestion so I'd like to pitch it again.

What about "Syntax.IntegerLiteralConsumer", which suggests that
conforming types can consume integer literal syntax as native to their
type.

--
Dave

It may be sorta esoteric, but I'd say it's a fair degree clearer to the intended
audience of Swift developers.

I ran a one-question poll last night about "Syntax.IntegerLiteralExpressible".
I asked what Swift developers (who were not following this discussion) thought it
meant.

The results can be found here:
https://www.surveymonkey.com/results/SM-FGMC93JT/
A tab at the top lets you view individual answers paired with explanations.

By a margin of at least like 9:1 (more if you include the freeform answers of "why" such as
answer 80, which says "It reminds me of StringLiteralExpressible which behaves that way.
But you're right, the name sounds like the other option.") developers thought that the
protocol meant (or should mean) that the conforming type could express itself as an integer
literal, and not that an integer literal can be expressed as the conforming type.

I encourage you to look at the individual responses. They include the freeform answers
that describe why each person chose as they did.

-- E

···

On Jun 27, 2016, at 8:46 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Maybe we could say that the type gives form to the literal or embodies
the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

You didn't respond to my earlier suggestion so I'd like to pitch it again.

What about "Syntax.IntegerLiteralConsumer", which suggests that
conforming types can consume integer literal syntax as native to their
type.

To me, the idea of a type (other than, say, a parser) consuming syntax
is pretty alien. So this one is sorta esoteric too, IMO.

--
Dave

Maybe we could say that the type gives form to the literal or embodies
the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

You didn't respond to my earlier suggestion so I'd like to pitch it again.

What about "Syntax.IntegerLiteralConsumer", which suggests that
conforming types can consume integer literal syntax as native to their
type.

To me, the idea of a type (other than, say, a parser) consuming syntax
is pretty alien. So this one is sorta esoteric too, IMO.

--
Dave

It may be sorta esoteric, but I'd say it's a fair degree clearer to the intended
audience of Swift developers.

I ran a one-question poll last night about "Syntax.IntegerLiteralExpressible".
I asked what Swift developers (who were not following this discussion) thought it
meant.

The results can be found here:
https://www.surveymonkey.com/results/SM-FGMC93JT/
A tab at the top lets you view individual answers paired with explanations.

By a margin of at least like 9:1 (more if you include the freeform answers of "why" such as
answer 80, which says "It reminds me of StringLiteralExpressible which behaves that way.
But you're right, the name sounds like the other option.") developers thought that the
protocol meant (or should mean) that the conforming type could express itself as an integer
literal, and not that an integer literal can be expressed as the
conforming type.

Which is exactly the right sense. Well, the only correct-ish option you
gave people is slightly awkward and inaccurate—I'd have said “Instances
of the conforming type can be expressed as integer literals,” but that
matches the 90% meaning almost exactly; certainly much better than the
10%.

As far as I can tell, your poll supports my suggestion.

···

on Tue Jun 28 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 27, 2016, at 8:46 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Jun 27 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

I encourage you to look at the individual responses. They include the
freeform answers that describe why each person chose as they did.

--
Dave