[Review] SE-0115: Rename Literal Syntax Protocols


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0115: Rename Literal Syntax Protocols" begins now and runs through July 7. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(David Sweeris) #2

I’d prefer the “namespace" idea, but a big +1 either way.
- Dave Sweeris

···

On Jul 1, 2016, at 6:07 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0115: Rename Literal Syntax Protocols" begins now and runs through July 7. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Brent Royal-Gordon) #3

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

Frankly, every name mentioned in that proposal basically sucks, including the old name, the new name, and all of the alternative names. I'm currently thinking about `WhateverLiteralCandidate`, `WhateverLiteralSyntax`, or `WhateverLiteralCompatible`, but those probably suck too. Kind of depressing, really.

Maybe we should just get rid of literals and have people write the raw bytes of the instances directly in their source code. That'll work, right?

···

--
Brent Royal-Gordon
Architechies


(Anton Zhilin) #4

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
    init(_ from: T)
}

And deprecate all the weird Convertibles.


(Charlie Monroe) #5

+0.5 - generally in favor, but I'm also leaning towards the "namespaced" alternative.

···

On Jul 2, 2016, at 1:07 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0115: Rename Literal Syntax Protocols" begins now and runs through July 7. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Roth Michaels) #6

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

  * What is your evaluation of the proposal?

+1 to the concept of the proposal.

I prefer some of the alternate names that have been discussed:
- ExpressibleByIntegerLiteral > ExpressibleAsIntegerLiteral
- Syntax.IntergerLiteralProtocol > ExpressibleByIntergerLiteral
- Syntax.Literal.IntegerProtocol > Syntax.IntergerLiteralProtocol

  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of
  Swift?

Increasing clarity of the names feels in line with the direction of
Swift, but I am not sure which naming convention would be the most
Swifty.

  * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

I have not previously looked at how this is implemented in other
languages.

  * How much effort did you put into your review? A glance, a
quick reading, or an in-depth study?

I casually followed the original discussion surrounding SE-0041.

I browsed the recent discussion on names to get a sense of which names
were being discussed in the community to try to offer some feedback with
minimal bike-shedding.

···

On Fri, Jul 01 2016 at 07:07:48 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

--
Roth Michaels
roth@rothmichaels.us


(Matthew Johnson) #7

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
   init(_ from: T)
}

This is extremely unlikely to happen. Generic protocols and multiple conformances are listed as unlikely in the generics manifesto. This *exact* use case is cited as the usual motivation for this feature and deemed insufficient.

If you want to see generic protocols and multiple conformances I think you're going to need to provide extremely compelling use cases in order for that proposal to be considered. And I would be surprised to see it make Swift 4 even if you do find sufficient motivation.

···

Sent from my iPad

On Jul 2, 2016, at 6:11 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

And deprecate all the weird Convertibles.

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


(Dave Abrahams) #8

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

···

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
    init(_ from: T)
}

And deprecate all the weird Convertibles.

--
-Dave


(Chris Lattner) #9

+1 for removing literals, that would definitely solve this naming problem ;-)

-Chris

···

On Jul 1, 2016, at 10:28 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md

Frankly, every name mentioned in that proposal basically sucks, including the old name, the new name, and all of the alternative names. I'm currently thinking about `WhateverLiteralCandidate`, `WhateverLiteralSyntax`, or `WhateverLiteralCompatible`, but those probably suck too. Kind of depressing, really.

Maybe we should just get rid of literals and have people write the raw bytes of the instances directly in their source code. That'll work, right?


(Riley Testut) #10

I kinda agree that these names still aren't the best. FWIW, I much preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

···

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
   init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

--
-Dave

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


(Riley Testut) #11

(My bad, accidentally hit send too early).

That, or we could keep either the Convert or Express forms with "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we decide "express" really is the best word to describe what happens, I personally prefer "IntegerLiteralExpressing" to "ExpressibleAsIntegerLiteral", which doesn't feel at home with the other Swift protocol names.

Riley

···

On Jul 2, 2016, at 10:49 AM, Riley Testut <rileytestut@gmail.com> wrote:

I kinda agree that these names still aren't the best. FWIW, I much preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
  init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

--
-Dave

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


(Dave Abrahams) #12

(My bad, accidentally hit send too early).

That, or we could keep either the Convert or Express forms with
"IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we
decide "express" really is the best word to describe what happens, I
personally prefer "IntegerLiteralExpressing" to
"ExpressibleAsIntegerLiteral", which doesn't feel at home with the
other Swift protocol names.

It doesn't matter if it “feels at home” if it has the wrong meaning.
It's not that Integer can express an integer literal; It's that an
integer literal can express an Integer.

When naming, we need to learn to stop treating the comfortable ring of
familiar word patterns as an arbiter of success.

···

on Sat Jul 02 2016, Riley Testut <rileytestut-AT-gmail.com> wrote:

Riley

On Jul 2, 2016, at 10:49 AM, Riley Testut <rileytestut@gmail.com> wrote:

I kinda agree that these names still aren't the best. FWIW, I much
preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
  init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

--
-Dave

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

--
-Dave


(Anton Zhilin) #13

Matthew Johnson via swift-evolution <swift-evolution@...> writes:

Sent from my iPad

>
> -1 from me. I suggest to wait until we get generic protocols
> in Swift 4, then we can use the following:
>
> protocol From<T> {
> init(_ from: T)
> }

This is extremely unlikely to happen. Generic protocols and multiple

conformances are listed as unlikely

in the generics manifesto. This *exact* use case is cited as the

usual motivation for this feature and

deemed insufficient.

If you want to see generic protocols and multiple conformances I think

you're going to need to provide

extremely compelling use cases in order for that proposal to be

considered. And I would be surprised to see

it make Swift 4 even if you do find sufficient motivation.

This became much more likely to happen after Brent suggested counter-
arguments and (I don't rembmer exactly, but) some core team members
didn't seem to mind.

The proposal:
https://github.com/Anton3/swift-evolution/blob/generic-
protocols/proposals/NNNN-generic-protocols.md

Brent's counterarguments:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-
20160606/020746.html

···

> On Jul 2, 2016, at 6:11 AM, Anton Zhilin via swift-evolution <swift- evolution <at> swift.org> wrote:


(Anton Zhilin) #14

Dave Abrahams via swift-evolution <swift-evolution@...> writes:

···

on Sat Jul 02 2016, Anton Zhilin <swift-evolution <at> swift.org> wrote:

> -1 from me. I suggest to wait until we get generic protocols
> in Swift 4, then we can use the following:
>
> protocol From<T> {
> init(_ from: T)
> }
>
> And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

I agree. Take whatever suffix you choose for the protocol series being
discussed, and name my protocol after that. Expressable<Int>,
Convertible<Bool>, Representable<String> all sound good to me. We just
need to pick an appropriate name.


(Adrian Zubarev) #15

To be honest, that’s why I suggested the idea of Literal.IntegerProtocol with the Protocol suffix.

If I’d read something like this extension Array : Literal.ArrayProtocol I won’t be confused what that protocol will do, because it doesn’t tell me the full behavior from its name. ErrorProtocol is very similar. To me it signals that it has something to do with the literal and arrays. If I’d look up the protocol and see that there is an associated type plus an initializer I’ll get the AHA moment and realize that with this protocol I can make an array literal into my type (or array in this example).

I’m not trying to push my personal suggestion. Decide however is best for the whole community. :wink:

···

--
Adrian Zubarev
Sent with Airmail

Am 2. Juli 2016 um 17:50:06, Riley Testut via swift-evolution (swift-evolution@swift.org) schrieb:

I kinda agree that these names still aren't the best. FWIW, I much preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

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


(Anton Zhilin) #16

>Anton Zhilin via swift-evolution <swift-evolution@...> writes:
> -1 from me. I suggest to wait until we get generic protocols
> in Swift 4, then we can use the following:
>
> protocol From<T> {
> init(_ from: T)
> }

I'm not sure this feature would be relevant in the case of literals. It

would definitely require something other than just From. What specific
design would you propose (assuming generic protocols) to replace the
protocols impacted by this proposal?

With From definition given above, I would define IntLiteralConvertible ===
From<Int>, BoolLiteralConvertible === From<Bool>, etc. That means, if you
conform to From<T> where T is one of Int, Bool, ... then the type becomes
"literal convertible".

From name and external label are discussable.

I'd also note that although the two proposals are not orthogonal, they do
not strictly conflict. I don't find it too bad if current renaming is
applied, and later the whole convertibles system is overhauled.

It's not globally important, but I've just invented a solution for
NilLiteralConvertible. We can make nil a value of type Nil:

enum Nil { case nil } // nil keyword is a macro for Nil.nil

And then From<Nil> will replace NilLiteralConvertible.


(Riley Testut) #17

When naming, we need to learn to stop treating the comfortable ring of
familiar word patterns as an arbiter of success.

I’m not sure I agree with this statement. I would argue we should most certainly aim to keep a consistent feel across our naming conventions, and furthermore, I think familiar word patterns greatly lowers barrier for entry for newcomers to the language. A big reason for so many of these renamings is because they don’t feel “Swifty”, and even if that might not be a good technical reason, I think it’s as valid a reason as any.

Following that, “ExpressibleAsIntegerLiteral” feels extremely un-swifty, and while technically you could argue it follows the Swift API Guidelines, the fact that it’s the only protocol with the adjective at the beginning and not the end is a giant red flag to me (unless I’m missing some).

A final thought: is it really better to have a technically correct name over one that, while technically incorrect, got its point across about how it should be used? This might just be me, but I would far prefer a name that from my interpretation would tell me how to use it, rather than one that would require me to think about what it actually means (as we’ve seen from all the confusion about what these protocols were actually doing).

Overall though, I’m glad there is this much debate about the future of these names, I think it will leave us with the best name (eventually) :-)

···

On Jul 2, 2016, at 2:53 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Sat Jul 02 2016, Riley Testut <rileytestut-AT-gmail.com <http://rileytestut-at-gmail.com/>> wrote:

(My bad, accidentally hit send too early).

That, or we could keep either the Convert or Express forms with
"IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we
decide "express" really is the best word to describe what happens, I
personally prefer "IntegerLiteralExpressing" to
"ExpressibleAsIntegerLiteral", which doesn't feel at home with the
other Swift protocol names.

It doesn't matter if it “feels at home” if it has the wrong meaning.
It's not that Integer can express an integer literal; It's that an
integer literal can express an Integer.

When naming, we need to learn to stop treating the comfortable ring of
familiar word patterns as an arbiter of success.

Riley

On Jul 2, 2016, at 10:49 AM, Riley Testut <rileytestut@gmail.com> wrote:

I kinda agree that these names still aren't the best. FWIW, I much
preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

--
-Dave

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

--
-Dave


(Adrian Zubarev) #18

Lets go back to the roots and create swifty-sembler. :slight_smile:

···

--
Adrian Zubarev
Sent with Airmail

Am 2. Juli 2016 um 18:35:15, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb:

+1 for removing literals, that would definitely solve this naming problem :wink:


(Anders) #19

(My bad, accidentally hit send too early).

That, or we could keep either the Convert or Express forms with
"IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we
decide "express" really is the best word to describe what happens, I
personally prefer "IntegerLiteralExpressing" to
"ExpressibleAsIntegerLiteral", which doesn't feel at home with the
other Swift protocol names.

It doesn't matter if it “feels at home” if it has the wrong meaning.
It's not that Integer can express an integer literal; It's that an
integer literal can express an Integer.

If "IntegerLiteralExpressing" describes the expressibility of a type as integer literals, "IntegerLiteralAccepting" would probably be the one describing the ability of a type to accept a integer literal.

···

On 3 Jul 2016, at 3:53 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sat Jul 02 2016, Riley Testut <rileytestut-AT-gmail.com <http://rileytestut-at-gmail.com/>> wrote:

When naming, we need to learn to stop treating the comfortable ring of
familiar word patterns as an arbiter of success.

Riley

On Jul 2, 2016, at 10:49 AM, Riley Testut <rileytestut@gmail.com> wrote:

I kinda agree that these names still aren't the best. FWIW, I much
preferred the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"?

On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Jul 02 2016, Anton Zhilin <swift-evolution@swift.org> wrote:

-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
init(_ from: T)
}

And deprecate all the weird Convertibles.

Even if we could do that, “From” would never be an appropriate name for
the ability to express a type as a particular kind of literal.

--
-Dave

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #20

Anton Zhilin via swift-evolution <swift-evolution@...> writes:
-1 from me. I suggest to wait until we get generic protocols
in Swift 4, then we can use the following:

protocol From<T> {
  init(_ from: T)
}

I'm not sure this feature would be relevant in the case of literals. It

would definitely require something other than just From. What specific
design would you propose (assuming generic protocols) to replace the
protocols impacted by this proposal?

With From definition given above, I would define IntLiteralConvertible ===
From<Int>, BoolLiteralConvertible === From<Bool>, etc. That means, if you
conform to From<T> where T is one of Int, Bool, ... then the type becomes
"literal convertible".

But that doesn't capture the semantics of these protocols. See the observations made by the library team quoted in the motivation section as well as Dave Abrahams' comments quoted in the alternatives section. None of this changes if we get generic protocols.

Protocols aren't just about the syntax, they are also about semantics. These protocols encode specific and important semantics.

···

Sent from my iPad
On Jul 2, 2016, at 9:10 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

From name and external label are discussable.

I'd also note that although the two proposals are not orthogonal, they do
not strictly conflict. I don't find it too bad if current renaming is
applied, and later the whole convertibles system is overhauled.

It's not globally important, but I've just invented a solution for
NilLiteralConvertible. We can make nil a value of type Nil:

enum Nil { case nil } // nil keyword is a macro for Nil.nil

And then From<Nil> will replace NilLiteralConvertible.

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