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
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
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?
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
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:
-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:
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?
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.
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.
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.
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.
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. ;)
···
--
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.
>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.
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:
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.
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.
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.