Revisiting SE-0041 Names


(Erica Sadun) #1

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. :slight_smile: 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.

Categories:
Type I: A protocol for types that can be initialized from specific types or protocols, e.g. created/initialized with strings (a specific type) or created/initialized with floating point numbers (conforming to a protocol). Current examples include "IntegerLiteralConvertible".
Type II: A protocol for types that can form a representation which may or may not provide a complete projection (the original may not be recoverable from that representation), e.g. "CustomStringConvertible" and "CustomPlaygroundQuickLookable" both fall into this.
Type III: A protocol for isomorphism: can be converted to and from a type, e.g. "RawRepresentable"

Existing Protocols:

AbsoluteValuable, AnyCollectionProtocol, AnyObject, ArrayLiteralConvertible, BidirectionalCollection, Collection, BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible, BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection, Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable, CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible, DictionaryLiteralConvertible, Equatable, ErrorProtocol, ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible, FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable, Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer, Strideable, IntegerArithmetic : _IntegerArithmetic, Comparable, IntegerLiteralConvertible, IteratorProtocol, LazyCollectionProtocol, LazySequenceProtocol, LazySequenceProtocol, MirrorPath, MutableCollection, Collection, MutableIndexable, NilLiteralConvertible, OptionSet, RawRepresentable, OutputStream, RandomAccessCollection, BidirectionalCollection, RandomAccessIndexable, RangeReplaceableCollection, Collection, RangeReplaceableIndexable, RawRepresentable, Sequence, SetAlgebra, ArrayLiteralConvertible, SignedInteger : _SignedInteger, Integer, SignedNumber, IntegerLiteralConvertible, Streamable, Strideable, StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec, UnicodeScalarLiteralConvertible, UnsignedInteger : _DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic : _Integer, _Incrementable, _Integer, CustomStringConvertible, Hashable, IntegerArithmetic, BitwiseOperations, _Incrementable, _IntegerArithmetic, _SequenceWrapper, _SignedInteger : _Integer, SignedNumber

Names (see: https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg)

Type I: Initializing
Type II: Representable
Type III: Isomorphic

Here's a paint brush. Have at it. And keep in mind the API-isms like "use nouns" (e.g. Sequence vs SequenceType) and "ing" (e.g. Initializing vs Initializable)

-- E


(Dmitri Gribenko) #2

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

- 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

···

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution <swift-evolution@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. :slight_smile: 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.

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


(David Sweeris) #3

I’m not sure I understand… In this example, has “IntegerLiteralConvertible” been renamed to “_IntegerLiteralSyntax”? If not, what’s it’s definition?

- Dave Sweeris

···

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

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

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


(Xiaodi Wu) #4

Quick thoughts:

Isomorphic is a delightful word.

Initializing has the wrong meaning, I think. If A conforms to
BInitializing, that reads to me like you can do B(A), not necessarily A(B).
By contrast, BInitializable conveys more clearly the sense that A can be
initialized with an argument of type B.

···

On Wed, Jun 22, 2016 at 13:04 Erica Sadun via swift-evolution < swift-evolution@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. :slight_smile: 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.

*Categories:*

   - Type I: A protocol for types that can be initialized from specific
   types or protocols, e.g. created/initialized with strings (a specific type)
   or created/initialized with floating point numbers (conforming to a
   protocol). Current examples include "IntegerLiteralConvertible".
   - Type II: A protocol for types that can form a representation which
   may or may not provide a complete projection (the original may not be
   recoverable from that representation), e.g. "CustomStringConvertible" and
   "CustomPlaygroundQuickLookable" both fall into this.
   - Type III: A protocol for isomorphism: can be converted to and from a
   type, e.g. "RawRepresentable"

*Existing Protocols:*

AbsoluteValuable, AnyCollectionProtocol, AnyObject,
ArrayLiteralConvertible, BidirectionalCollection, Collection,
BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible,
BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection,
Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable,
CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible,
DictionaryLiteralConvertible, Equatable, ErrorProtocol,
ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible,
FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable,
Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer,
Strideable, IntegerArithmetic : _IntegerArithmetic, Comparable,
IntegerLiteralConvertible, IteratorProtocol, LazyCollectionProtocol,
LazySequenceProtocol, LazySequenceProtocol, MirrorPath, MutableCollection,
Collection, MutableIndexable, NilLiteralConvertible, OptionSet,
RawRepresentable, OutputStream, RandomAccessCollection,
BidirectionalCollection, RandomAccessIndexable, RangeReplaceableCollection,
Collection, RangeReplaceableIndexable, RawRepresentable, Sequence,
SetAlgebra, ArrayLiteralConvertible, SignedInteger : _SignedInteger,
Integer, SignedNumber, IntegerLiteralConvertible, Streamable, Strideable,
StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec,
UnicodeScalarLiteralConvertible, UnsignedInteger :
_DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic :
_Integer, _Incrementable, _Integer, CustomStringConvertible, Hashable,
IntegerArithmetic, BitwiseOperations, _Incrementable, _IntegerArithmetic,
_SequenceWrapper, _SignedInteger : _Integer, SignedNumber

*Names (see: https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg
<https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg>)*

Type I: Initializing
Type II: Representable
Type III: Isomorphic

Here's a paint brush. Have at it. And keep in mind the API-isms like "use
nouns" (e.g. Sequence vs SequenceType) and "ing" (e.g. Initializing vs
Initializable)

-- E

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


(Matthew Johnson) #5

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. :slight_smile: 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 {}

Is anyone on the core team planning to write up a proposal for this change? If not, I will be happy to do it. It solves the biggest issue I have with the current state (two different meanings for “Convertible”). I will be happy to see this solved while we’re making breaking changes. :slight_smile:

···

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:

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


(Matthew Johnson) #6

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

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

···

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:

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


(Dave Abrahams) #7

Yes, that's the idea.

···

on Wed Jun 22 2016, David Sweeris <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:

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

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

I’m not sure I understand… In this example, has
“IntegerLiteralConvertible” been renamed to “_IntegerLiteralSyntax”?

--
Dave


(Dmitri Gribenko) #8

That's right. But we want users to refer to the protocol as
'Syntax.IntegerLiteral'. If/once we get either submodules or
protocols nested in enums, we can move the actual definition to be
nested.

Dmitri

···

On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris <davesweeris@mac.com> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:

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

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

I’m not sure I understand… In this example, has “IntegerLiteralConvertible” been renamed to “_IntegerLiteralSyntax”?

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


(David Sweeris) #9

Yeah, I’d be inclined to name it “InitableFromB” rather than “BInitializing”.

- Dave Sweeris

···

On Jun 22, 2016, at 1:40 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Quick thoughts:

Isomorphic is a delightful word.

Initializing has the wrong meaning, I think. If A conforms to BInitializing, that reads to me like you can do B(A), not necessarily A(B). By contrast, BInitializable conveys more clearly the sense that A can be initialized with an argument of type B.


(Dave Abrahams) #10

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. :slight_smile: 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 {}

Is anyone on the core team planning to write up a proposal for this
change?

Not currently.

If not, I will be happy to do it.

That's much appreciated!

···

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:

It solves the biggest issue I have with the current state (two
different meanings for “Convertible”). I will be happy to see this
solved while we’re making breaking changes. :slight_smile:

- 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


(Dmitri Gribenko) #11

Your help would be most appreciated!

Dmitri

···

On Wed, Jun 22, 2016 at 4:43 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
protocol _IntegerLiteralSyntax {}
enum Syntax {
typealias IntegerLiteral = _IntegerLiteralSyntax
}

And used like this:

struct Int : Syntax.IntegerLiteral {}

Is anyone on the core team planning to write up a proposal for this change?

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


(David Sweeris) #12

That's a really interesting idea. Is "Syntax" a placeholder, or is that the intended name? Also, why an enum? Especially one without any cases...

Was all this already discussed in a thread that I missed (or have otherwise forgotten about)?

- Dave Sweeris

···

Sent from my iPhone

On Jun 22, 2016, at 15:54, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris <davesweeris@mac.com> wrote:

On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:

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

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

I’m not sure I understand… In this example, has “IntegerLiteralConvertible” been renamed to “_IntegerLiteralSyntax”?

That's right. But we want users to refer to the protocol as
'Syntax.IntegerLiteral'. If/once we get either submodules or
protocols nested in enums, we can move the actual definition to be
nested.

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


(Dmitri Gribenko) #13

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. :slight_smile: 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

···

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

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


(Dave Abrahams) #14

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. :slight_smile: 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.

···

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:

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


(Dmitri Gribenko) #15

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.

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.

Was all this already discussed in a thread that I missed (or have otherwise forgotten about)?

This feedback was provided in one of the threads about SE-0041, but I
can't find the link. It did not get much discussion at that time.

Dmitri

···

On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris@mac.com> wrote:

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


(David Sweeris) #16

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.

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

- Dave Sweeris

···

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:


(Matthew Johnson) #17

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. :slight_smile: 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.

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. :slight_smile:

···

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:

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Erica Sadun) #18

Starting with this:

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

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.

-- E

···

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

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.


(Xiaodi Wu) #19

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

···

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

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


(Shawn Erickson) #20

I like how your suggestion reads. It will namespace all literal
convertibles while also reading more clearly on what conforming to the
protocol implies. I now understand the intent of the Syntax namespace
however I think you suggested naming would be better.

-Shawn

···

On Wed, Jun 22, 2016 at 11:26 PM 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.

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

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