[Proposal Draft] Literal Syntax Protocols

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

1 Like

My only feedback at the moment is that “Syntax” seems like a weird name.

This is all about literals, right? So why not use:

Literal.Integer
Literal.Float
Literal.String

etc.

l8r
Sean

···

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

  • Proposal: SE-NNNN
  • Author: Matthew Johnson
  • Status: Awaiting review
  • Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names

Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)

An earlier proposal was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible
{ ... }

public protocol BooleanLiteralConvertible
{ ... }

public protocol FloatLiteralConvertible
{ ... }

public protocol IntegerLiteralConvertible
{ ... }

public protocol UnicodeScalarLiteralConvertible
{ ... }

public protocol ExtendedGraphemeClusterConvertible
{ ... }

public protocol StringLiteralLiteralConvertible
{ ... }

public protocol StringInterpolationLiteralConvertible
{ ... }

public protocol ArrayLiteralConvertible
{ ... }

public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax
{ ... }

public protocol _BooleanLiteralSyntax
{ ... }

public protocol _IntegerLiteralSyntax
{ ... }

public protocol _FloatLiteralSyntax
{ ... }

public protocol _UnicodeScalarLiteralSyntax
{ ... }

public protocol _ExtendedGraphemeClusterLiteralSyntax
{ ... }

public protocol _StringLiteralLiteralSyntax
{ ... }

public protocol _StringInterpolationLiteralSyntax
{ ... }

public protocol _ArrayLiteralSyntax
{ ... }

public protocol _DictionaryLiteralSyntax
{ ... }

public /* closed */ enum Syntax
{
  
public typealias NilLiteral
= _NilLiteralSyntax
  
public typealias BooleanLiteral
= _BooleanLiteralSyntax
  
public typealias IntegerLiteral
= _IntegerLiteralSyntax
  
public typealias FloatLiteral
= _FloatLiteralSyntax
  
public typealias UnicodeScalarLiteral
= _UnicodeScalarLiteralSyntax
  
public typealias ExtendedGraphemeClusterLiteral
= _ExtendedGraphemeClusterLiteralSyntax
  
public typealias StringLiteralLiteral
= _StringLiteralLiteralSyntax
  
public typealias StringInterplolationLiteral
= _StringInterpolationLiteralSyntax
  
public typealias ArrayrLiteral
= _ArrayLiteralSyntax
  
public typealias DictionaryLiteral
= _DictionaryLiteralSyntax
}

Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

I like the namespace-based approach to group these protocols together and I'm very happy to see some clarification happening in this group of protocols. However, I don't think the proposed new names communicate what they need to. The names listed in the "Alternatives Considered" section do a better job of describing the use and behavior of these protocols.

Primarily, the new names read like we're saying that a conforming type is a literal, compounding a common existing confusion between literals and types that can be initialized with a literal. Swift's type inference can sometimes make it seem like dark magic is afoot with literal conversions—for example, you need to understand an awful lot about the standard library to figure out why line 1 works here but not line 2:

    var x = [1, 2, 3, 4, 5]
    let y = [10, 20]

    x[1..<2] = [10, 20] // 1
    x[1..<2] = y // 2

These new names are a (small) step in the wrong direction. While it's true that the type system doesn't have an IntegerLiteral type, the language does have integer literals. If someone reads:

    extension MyInt : Syntax.IntegerLiteral { ... }

the implication is that MyInt is an integer literal, and therefore instances of MyInt should be usable wherever an integer literal is usable. The existing "Convertible" wording may be a red herring, but it at least suggests that there's a difference between a literal and a concrete type.

In sum, I support a change like this and strongly recommend keeping some sort of adjective in the protocol name.

Nate

···

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

+1

“Syntax” still feels weird, though…

Oh, so if the idea is that literals don’t have a type, that the “Syntax” isn’t meant to be exclusively about literals, and that the various `*LiteralConvertible` protocols only exist to tell the -->compiler<-- what types any given literal can become, what about just calling it “Compiler”?
struct Foo : Compiler.IntegerLiteral {}

This reinforces the notion (at least in my mind, and at least more than “Syntax” does) that literals live outside of Swift’s "normal" type system.

- Dave Sweeris

···

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

What an disturbing name... 'Syntax.xxx'
it makes me anticipate basically a proliferation of other:
NarrowLittleCornerCase.yyyy
YetAnotherNameToIsolateSomethingElseFromTheRest.zzzz

It evokes to me the "File file" naming pattern (compared to 'File settings' or 'File avatarImage')
Regards
LM
(From mobile)

···

On Jun 23, 2016, at 5:31 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN
Author: Matthew Johnson
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names

Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

+1 from me. If I'll see `struct A : Syntax.NilLiteral {..}` I read this as "`A` could be represented in syntax as nil literal" or even "A could be a nil literal in syntax"

···

On 23.06.2016 18:31, Matthew Johnson via swift-evolution wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible`
protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found
here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\.
It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

  Literal Syntax Protocols

  * Proposal: SE-NNNN
  * Author: Matthew Johnson <https://github.com/anandabits&gt;
  * Status: *Awaiting review*
  * Review manager: TBD

    Introduction

This proposal renames the |*LiteralConvertible| protocols
to |Syntax.*Literal|.

Swift-evolution thread: Revisiting SE–0041 Names
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;

    Motivation

The standard library currently has protocols that use the
term |Convertible| in two different ways.
The |*LiteralConvertible| protocols use the meaning of converting /from/ a
literal. The |Custom(Debug)StringConvertible| protocols use the meaning of
converting /to/ a |String|. This causes confusion for developers attempting
to name their own protocols following the precedence established by the
standard library.

Further, the standard library team has observed:

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

An earlier proposal
<https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was
intended to address the first problem by introducing strong naming
conventions for three kinds of conversion protocols (/from/, /to/,
and /bidirectional/). The review highlighted the difficulity in
establishing conventions that everyone is happy with. This proposal takes a
different approach to solving the problem that originally inspired that
proposal while also solving the awkwardness of the current names described
by the standard library team.

    Proposed solution

This proposal addresses both problems by introducing a |Syntax| “namespace”
and moving the |*LiteralConvertible| protocols into that “namespace” while
also renaming them. The proposal *does not* make any changes to the
requirements of the protocols.

    Detailed design

All of the |*LiteralConvertible| protocols will receive
new |*Literal| names inside a |Syntax|namespace.

This namespace will initially be implemented using a case-less |enum|, but
this detail may change in the future if submodules or namespaces are added
to Swift. Swift does not currently allow protocols to be declared inside
the scope of a type. In order to work around this limitation the protocols
themselves will be declared using underscore-prefixed names internal to the
standard library. Typealiases inside the |Syntax| enum will declare the
names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All
requirements of all |*LiteralConvertible| protocols will remain exactly the
same.

The following protocol declarations and names:

>public protocol NilLiteralConvertible { ... } public protocol
BooleanLiteralConvertible { ... } public protocol FloatLiteralConvertible {
... } public protocol IntegerLiteralConvertible { ... } public protocol
UnicodeScalarLiteralConvertible { ... } public protocol
ExtendedGraphemeClusterConvertible { ... } public protocol
StringLiteralLiteralConvertible { ... } public protocol
StringInterpolationLiteralConvertible { ... } public protocol
ArrayLiteralConvertible { ... } public protocol
DictionaryLiteralConvertible { ... }|

Are changed as follows:

>public protocol _NilLiteralSyntax { ... } public protocol
_BooleanLiteralSyntax { ... } public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... } public protocol
_UnicodeScalarLiteralSyntax { ... } public protocol
_ExtendedGraphemeClusterLiteralSyntax { ... } public protocol
_StringLiteralLiteralSyntax { ... } public protocol
_StringInterpolationLiteralSyntax { ... } public protocol
_ArrayLiteralSyntax { ... } public protocol _DictionaryLiteralSyntax { ...
} public /* closed */ enum Syntax { public typealias NilLiteral =
_NilLiteralSyntax public typealias BooleanLiteral = _BooleanLiteralSyntax
public typealias IntegerLiteral = _IntegerLiteralSyntax public typealias
FloatLiteral = _FloatLiteralSyntax public typealias UnicodeScalarLiteral =
_UnicodeScalarLiteralSyntax public typealias ExtendedGraphemeClusterLiteral
= _ExtendedGraphemeClusterLiteralSyntax public typealias
StringLiteralLiteral = _StringLiteralLiteralSyntax public typealias
StringInterplolationLiteral = _StringInterpolationLiteralSyntax public
typealias ArrayrLiteral = _ArrayLiteralSyntax public typealias
DictionaryLiteral = _DictionaryLiteralSyntax }|

    Impact on existing code

All code that references any of the |*LiteralConvertible| protocols will
need to be modified to reference the protocol via the
new |Syntax.*Literal| name.

    Alternatives considered

      Protocol names

Several commenters have suggested that the names in this proposal are
confusing at the site of use:

>struct Foo: Syntax.IntegerLiteral { ... }|

One alternative naming scheme would emphasize the semantic of initializing
the type with a literal:

>struct Foo: Syntax.IntegerLiteralInitializable { ... }|

Discussion of the pros and cons of the proposed and alternative naming
schemes is encouraged. The core team should feel free to make a final
decision on the exact naming scheme used if they choose to accept this
proposal.

      Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for
Conversions
<https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\.
Many related alternatives were explored during the discussion and review of
that proposal.

    Acknowledgements

The design described in this proposal was suggested by Dave Abrahams,
Dmitri Gribenko, and Maxim Moiseev.

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

Syntax by itself is not clear enough. Appending Initializable makes it too long.

We can replace Syntax with LiteralSyntax to clarify. Then we will have:

extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ }

Better yet, to address the valid concern of doing something so different and hack-like for literals, how about simply renaming *LiteralConvertible protocols to *LiteralSyntax or LiteralSyntax*. The key is the LiteralSyntax phrase which (I think) is the clearest short phrase we can get to communicate the intent. Look: It is right there in the title!

···

On Jun 23, 2016, at 8:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

<https://github.com/apple/swift-evolution/pull/381&gt;

CORRECTIONS:

Find: "ExtendedGraphemeClusterConvertible"
Replace: "ExtendedGraphemeClusterLiteralConvertible"

Find: "StringInterpolationLiteralConvertible"
Replace: "StringInterpolationConvertible"

Find: "StringLiteralLiteral" (x5)
Replace: "StringLiteral"

Find: "ArrayrLiteral"
Replace: "ArrayLiteral"

SUGGESTIONS:

Should the `DictionaryLiteral` structure be renamed?
<https://developer.apple.com/reference/swift/dictionaryliteral&gt;
It isn't a dictionary or a literal, it's an ordered collection.

Can we also change `ExtendedGraphemeCluster` to `Character`?
This would affect the argument label, global type alias, etc.

-- Ben

My only feedback at the moment is that “Syntax” seems like a weird name.

This name was suggested by the standard library team. I believe the intent is to place all syntax-supporting protocols in it. The only syntax-supporting protocols we have right now are literals but that may not always be the case. I'll let the team elaborate further if they have anything to add.

···

Sent from my iPad

On Jun 23, 2016, at 10:39 AM, Sean Heber <sean@fifthace.com> wrote:

This is all about literals, right? So why not use:

Literal.Integer
Literal.Float
Literal.String

etc.

l8r
Sean

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

   • Proposal: SE-NNNN
   • Author: Matthew Johnson
   • Status: Awaiting review
   • Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names

Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)

An earlier proposal was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible
{ ... }

public protocol BooleanLiteralConvertible
{ ... }

public protocol FloatLiteralConvertible
{ ... }

public protocol IntegerLiteralConvertible
{ ... }

public protocol UnicodeScalarLiteralConvertible
{ ... }

public protocol ExtendedGraphemeClusterConvertible
{ ... }

public protocol StringLiteralLiteralConvertible
{ ... }

public protocol StringInterpolationLiteralConvertible
{ ... }

public protocol ArrayLiteralConvertible
{ ... }

public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax
{ ... }

public protocol _BooleanLiteralSyntax
{ ... }

public protocol _IntegerLiteralSyntax
{ ... }

public protocol _FloatLiteralSyntax
{ ... }

public protocol _UnicodeScalarLiteralSyntax
{ ... }

public protocol _ExtendedGraphemeClusterLiteralSyntax
{ ... }

public protocol _StringLiteralLiteralSyntax
{ ... }

public protocol _StringInterpolationLiteralSyntax
{ ... }

public protocol _ArrayLiteralSyntax
{ ... }

public protocol _DictionaryLiteralSyntax
{ ... }

public /* closed */ enum Syntax
{

public typealias NilLiteral
= _NilLiteralSyntax

public typealias BooleanLiteral
= _BooleanLiteralSyntax

public typealias IntegerLiteral
= _IntegerLiteralSyntax

public typealias FloatLiteral
= _FloatLiteralSyntax

public typealias UnicodeScalarLiteral
= _UnicodeScalarLiteralSyntax

public typealias ExtendedGraphemeClusterLiteral
= _ExtendedGraphemeClusterLiteralSyntax

public typealias StringLiteralLiteral
= _StringLiteralLiteralSyntax

public typealias StringInterplolationLiteral
= _StringInterpolationLiteralSyntax

public typealias ArrayrLiteral
= _ArrayLiteralSyntax

public typealias DictionaryLiteral
= _DictionaryLiteralSyntax
}

Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

I like the namespace-based approach to group these protocols together and I'm very happy to see some clarification happening in this group of protocols. However, I don't think the proposed new names communicate what they need to. The names listed in the "Alternatives Considered" section do a better job of describing the use and behavior of these protocols.

Primarily, the new names read like we're saying that a conforming type is a literal, compounding a common existing confusion between literals and types that can be initialized with a literal. Swift's type inference can sometimes make it seem like dark magic is afoot with literal conversions—for example, you need to understand an awful lot about the standard library to figure out why line 1 works here but not line 2:

    var x = [1, 2, 3, 4, 5]
    let y = [10, 20]

    x[1..<2] = [10, 20] // 1
    x[1..<2] = y // 2

These new names are a (small) step in the wrong direction. While it's true that the type system doesn't have an IntegerLiteral type, the language does have integer literals. If someone reads:

    extension MyInt : Syntax.IntegerLiteral { ... }

the implication is that MyInt is an integer literal, and therefore instances of MyInt should be usable wherever an integer literal is usable. The existing "Convertible" wording may be a red herring, but it at least suggests that there's a difference between a literal and a concrete type.

In sum, I support a change like this and strongly recommend keeping some sort of adjective in the protocol name.

I appreciate your comments Nate. Do you mind if I paste some of this into the proposal in the alternatives considered section?

I tend to agree with this and prefer the `Syntax.*LiteralInitializable` names myself. However, the standard library team seems to prefer the names in the proposal.

I have already had a related proposal rejected because the core team didn’t like the names in the proposal so I am taking a conservative approach here of writing the proposal using the names they prefer and listing my preference as an alternative. I am hoping community feedback will prompt the core team to accept a revised version with names that are a bit more clear. Short of that, I am hoping to avoid rejection as I think the proposal as-written is an improvement over current state.

···

On Jun 23, 2016, at 11:43 AM, Nate Cook <natecook@gmail.com> wrote:

Nate

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

+1

“Syntax” still feels weird, though…

Oh, so if the idea is that literals don’t have a type, that the “Syntax” isn’t meant to be exclusively about literals, and that the various `*LiteralConvertible` protocols only exist to tell the -->compiler<-- what types any given literal can become, what about just calling it “Compiler”?
struct Foo : Compiler.IntegerLiteral {}

This reinforces the notion (at least in my mind, and at least more than “Syntax” does) that literals live outside of Swift’s "normal" type system.

Thanks for the feedback. `Compiler` seems like a reasonable alternative. I will add it to the proposal. I anticipate plenty of bike shedding during discussion / review and want to encourage the community to debate the pros and cons of the options we are able to come up with.

···

On Jun 23, 2016, at 12:26 PM, David Sweeris <davesweeris@mac.com> wrote:

- Dave Sweeris

On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

Thanks for the feedback Adrian!

I don’t like an underscore on public protocols. If we’re not forced to use the proposed syntax at all it looks strange when you use a type with an underscore (which to me represents something for private or internal usage).

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

In Swift we only can use literals for a single direction literal -> type, so why don’t we just rename the protocols to look like:

This is a reasonable suggestion. I’ll add it to the alternatives section.

···

On Jun 24, 2016, at 10:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
public protocol NilLiteralProtocol { ... }
public protocol BooleanLiteralProtocol { ... }
public protocol FloatLiteralProtocol { ... }
public protocol IntegerLiteralProtocol { ... }
public protocol UnicodeScalarLiteralProtocol { ... }
public protocol ExtendedGraphemeClusterProtocol { ... }
public protocol StringLiteralLiteralProtocol { ... }
public protocol StringInterpolationLiteralProtocol { ... }
public protocol ArrayLiteralProtocol { ... }
public protocol DictionaryLiteralProtocol { ... }
Here Protocol corresponds to the user that we’re about to access a specific literal with our type which implements the protocol. (Just like ErrorProtocol.)
- extension Array : ArrayLiteralConvertible
+ extension Array : ArrayLiteralProtocol

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 16:21:21, Vladimir.S via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

es are

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

I don’t like an underscore on public protocols. If we’re not forced to use the proposed syntax at all it looks strange when you use a type with an underscore (which to me represents something for private or internal usage).

In Swift we only can use literals for a single direction literal -> type, so why don’t we just rename the protocols to look like:

public protocol NilLiteralProtocol { ... }
public protocol BooleanLiteralProtocol { ... }
public protocol FloatLiteralProtocol { ... }
public protocol IntegerLiteralProtocol { ... }
public protocol UnicodeScalarLiteralProtocol { ... }
public protocol ExtendedGraphemeClusterProtocol { ... }
public protocol StringLiteralLiteralProtocol { ... }
public protocol StringInterpolationLiteralProtocol { ... }
public protocol ArrayLiteralProtocol { ... }
public protocol DictionaryLiteralProtocol { ... }
Here Protocol corresponds to the user that we’re about to access a specific literal with our type which implements the protocol. (Just like ErrorProtocol.)
- extension Array : ArrayLiteralConvertible
+ extension Array : ArrayLiteralProtocol

···

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 16:21:21, Vladimir.S via swift-evolution (swift-evolution@swift.org) schrieb:

es are

what about `*LiteralRepresentable`?

···

On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote:

Syntax by itself is not clear enough. Appending Initializable makes it too
long.

We can replace Syntax with LiteralSyntax to clarify. Then we will have:

extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ }

Better yet, to address the valid concern of doing something so different
and hack-like for literals, how about simply *renaming
*LiteralConvertible protocols to *LiteralSyntax or LiteralSyntax*.* The
key is the *LiteralSyntax* phrase which (I think) is the clearest short
phrase we can get to communicate the intent. Look: It is right there in the
title!

On Jun 23, 2016, at 8:31 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible`
protocols into a `Syntax` namespace as suggested by the standard library
team.

The draft can be found here:
https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It
is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

   - Proposal: SE-NNNN
   - Author: Matthew Johnson <https://github.com/anandabits&gt;
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal
.

Swift-evolution thread: Revisiting SE–0041 Names
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in
two different ways. The *LiteralConvertible protocols use the meaning of
converting *from* a literal. The Custom(Debug)StringConvertible protocols
use the meaning of converting *to* a String. This causes confusion for
developers attempting to name their own protocols following the precedence
established by the standard library.

Further, the standard library team has observed:

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)

An earlier proposal
<https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was
intended to address the first problem by introducing strong naming
conventions for three kinds of conversion protocols (*from*, *to*, and
*bidirectional*). The review highlighted the difficulity in establishing
conventions that everyone is happy with. This proposal takes a different
approach to solving the problem that originally inspired that proposal
while also solving the awkwardness of the current names described by the
standard library team.
Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace”
and moving the *LiteralConvertible protocols into that “namespace” while
also renaming them. The proposal *does not* make any changes to the
requirements of the protocols.
Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names
inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but
this detail may change in the future if submodules or namespaces are added
to Swift. Swift does not currently allow protocols to be declared inside
the scope of a type. In order to work around this limitation the protocols
themselves will be declared using underscore-prefixed names internal to the
standard library. Typealiases inside the Syntax enum will declare the
names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All
requirements of all *LiteralConvertible protocols will remain exactly the
same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }public protocol BooleanLiteralConvertible { ... }public protocol FloatLiteralConvertible { ... }public protocol IntegerLiteralConvertible { ... }public protocol UnicodeScalarLiteralConvertible { ... }public protocol ExtendedGraphemeClusterConvertible { ... }public protocol StringLiteralLiteralConvertible { ... }public protocol StringInterpolationLiteralConvertible { ... }public protocol ArrayLiteralConvertible { ... }public protocol DictionaryLiteralConvertible { ... }

Are changed as follows:

public protocol _NilLiteralSyntax { ... }public protocol _BooleanLiteralSyntax { ... }public protocol _IntegerLiteralSyntax { ... }public protocol _FloatLiteralSyntax { ... }public protocol _UnicodeScalarLiteralSyntax { ... }public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }public protocol _StringLiteralLiteralSyntax { ... }public protocol _StringInterpolationLiteralSyntax { ... }public protocol _ArrayLiteralSyntax { ... }public protocol _DictionaryLiteralSyntax { ... }
public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}

Impact on existing code

All code that references any of the *LiteralConvertible protocols will
need to be modified to reference the protocol via the new Syntax.*Literal
name.
Alternatives consideredProtocol names

Several commenters have suggested that the names in this proposal are
confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }

One alternative naming scheme would emphasize the semantic of initializing
the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }

Discussion of the pros and cons of the proposed and alternative naming
schemes is encouraged. The core team should feel free to make a final
decision on the exact naming scheme used if they choose to accept this
proposal.
Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for
Conversions
<https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\.
Many related alternatives were explored during the discussion and review of
that proposal.
Acknowledgements

The design described in this proposal was suggested by Dave Abrahams,
Dmitri Gribenko, and Maxim Moiseev.
_______________________________________________
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

<https://github.com/apple/swift-evolution/pull/381&gt;

CORRECTIONS:

Find: "ExtendedGraphemeClusterConvertible"
Replace: "ExtendedGraphemeClusterLiteralConvertible"

Find: "StringInterpolationLiteralConvertible"
Replace: "StringInterpolationConvertible"

Find: "StringLiteralLiteral" (x5)
Replace: "StringLiteral"

Find: "ArrayrLiteral"
Replace: "ArrayLiteral"

SUGGESTIONS:

Should the `DictionaryLiteral` structure be renamed?
<https://developer.apple.com/reference/swift/dictionaryliteral&gt;
It isn't a dictionary or a literal, it's an ordered collection.

Can we also change `ExtendedGraphemeCluster` to `Character`?
This would affect the argument label, global type alias, etc.

Thanks for catching these mistakes! Looks like my late night copy / pasting and proofreading skills could use some improvement. :)

I want to keep this proposal as tightly focused as possible so it has maximum chance of acceptance. If you want to propose renaming the root of a couple of these protocols you should pursue an independent proposal for that.

Matthew

···

On Jun 27, 2016, at 7:40 AM, Ben Rimmington <me@benrimmington.com> wrote:

-- Ben

Syntax by itself is not clear enough. Appending Initializable makes it too long.

We can replace Syntax with LiteralSyntax to clarify. Then we will have:

extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ }

Better yet, to address the valid concern of doing something so different and hack-like for literals, how about simply renaming *LiteralConvertible protocols to *LiteralSyntax or LiteralSyntax*. The key is the LiteralSyntax phrase which (I think) is the clearest short phrase we can get to communicate the intent. Look: It is right there in the title!

This looks reasonable if you only focus on the existing protocols. However, I believe the intent of this namespace is that it can support any syntax-related protocols that might emerge in the future whether they are related to literals or not. With that in mind, I don’t think `LiteralSyntax` will fly as it isn’t general enough to support that.

···

On Jun 26, 2016, at 10:11 AM, Hooman Mehr <hooman@mac.com> wrote:

On Jun 23, 2016, at 8:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <file:///Users/Matthew/Library/Containers/com.brettterpstra.marked2/Data/Library/Caches/Marked%202/Watchers/NNNN-literal-syntax-protocols.md>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

DictionaryLiteral seems fine to me; it's as much a dictionary as
ArrayLiteral is an array, right?

What's wrong with ExtendedGraphemeCluster? It precisely self-documents what
must exist between the double quotes to qualify as such a literal. Plus, we
don't have e.g. a single-quoted character type; the name CharacterLiteral
is a misnomer for what's effectively a string literal constrained by length.

Likewise, it's not a StringInterpolationLiteral but StringInterpolation;
there's no syntax for demarcating it, so it's a string literal constrained
by what's between the double quotes.

···

On Mon, Jun 27, 2016 at 08:40 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote:

<https://github.com/apple/swift-evolution/pull/381&gt;

CORRECTIONS:

Find: "ExtendedGraphemeClusterConvertible"
Replace: "ExtendedGraphemeClusterLiteralConvertible"

Find: "StringInterpolationLiteralConvertible"
Replace: "StringInterpolationConvertible"

Find: "StringLiteralLiteral" (x5)
Replace: "StringLiteral"

Find: "ArrayrLiteral"
Replace: "ArrayLiteral"

SUGGESTIONS:

Should the `DictionaryLiteral` structure be renamed?
<https://developer.apple.com/reference/swift/dictionaryliteral&gt;
It isn't a dictionary or a literal, it's an ordered collection.

Can we also change `ExtendedGraphemeCluster` to `Character`?
This would affect the argument label, global type alias, etc.

-- Ben

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

DictionaryLiteral seems fine to me; it's as much a dictionary as ArrayLiteral is an array, right?

The `DictionaryLiteral` *structure* isn't a hash table.
It's an array of key-value pairs, and allows duplicate keys.
Entries are accessed by their position, not by their key.
<https://developer.apple.com/reference/swift/dictionaryliteral&gt;

What's wrong with ExtendedGraphemeCluster? It precisely self-documents what must exist between the double quotes to qualify as such a literal. Plus, we don't have e.g. a single-quoted character type; the name CharacterLiteral is a misnomer for what's effectively a string literal constrained by length.

The `ExtendedGraphemeCluster` prefix is verbose.
The `Character` *structure* is already defined as:
"A single extended grapheme cluster, ..."
Why have different names for the same concept?
<https://developer.apple.com/reference/swift/character&gt;

Likewise, it's not a StringInterpolationLiteral but StringInterpolation; there's no syntax for demarcating it, so it's a string literal constrained by what's between the double quotes.

The design team suggested `InterpolatedStringLiteral` in their SE-0041 feedback.
<https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md#response-to-design-team-feedback&gt;

I suggested using protocol inheritance.
<http://article.gmane.org/gmane.comp.lang.swift.evolution/17229&gt;

-- Ben

···

On 27 Jun 2016, at 14:37, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

No, it's exactly the opposite, as I keep saying. Conformance to this
protocol does *not* mean you can initialize the type with a literal.
Proof:

  func f<T: IntegerLiteralConvertible>() -> T {
    return T(integerLiteral: 43) // Error
    return T(43) // Also an Error
  }

It means an instance of the type can be *written* as a literal:

  func f<T: IntegerLiteralConvertible>() -> T {
    return 43 // OK
  }

Everybody's confused about the meaning of the protocol, and doesn't like
the proposed names because they imply exactly the actual meaning of the
protocol, which they misunderstand.

···

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

I like the namespace-based approach to group these protocols together
and I'm very happy to see some clarification happening in this group
of protocols. However, I don't think the proposed new names
communicate what they need to. The names listed in the "Alternatives
Considered" section do a better job of describing the use and behavior
of these protocols.

Primarily, the new names read like we're saying that a conforming type
is a literal, compounding a common existing confusion between literals
and types that can be initialized with a literal.

--
Dave

This is already rejected for not being clear enough. We can express some Double values using integer literal syntax, because integers are a subset of floating point numbers but not the other way around. Representable seems to imply it should work both ways.

*LiteralConvertible protocols indicate that we can always use the syntax of the given kind[1] of literal to create an instance of that type. This operation is inherently one way as Literal is a concept that is defined in the context of the source code under compilation.

Compiler converts a literal (a stream of characters in the source code that adhere to the syntax of a given kind of literal) to an instance of some type. This is where the original Convertible comes from.

As you see this is all about compiler and language syntax. That is why the new round of suggested names focus on Compiler and Syntax words to keep the domain clear. It is unfortunate that it does not fit the API guidelines protocol naming conventions.

[1] I am avoiding the use of word “type” here to avoid confusion.

···

On Jun 26, 2016, at 10:06 AM, T.J. Usiyan <griotspeak@gmail.com> wrote:

what about `*LiteralRepresentable`?

On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Syntax by itself is not clear enough. Appending Initializable makes it too long.

We can replace Syntax with LiteralSyntax to clarify. Then we will have:

extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ }

Better yet, to address the valid concern of doing something so different and hack-like for literals, how about simply renaming *LiteralConvertible protocols to *LiteralSyntax or LiteralSyntax*. The key is the LiteralSyntax phrase which (I think) is the clearest short phrase we can get to communicate the intent. Look: It is right there in the title!

On Jun 23, 2016, at 8:31 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team.

The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56\. It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew

Literal Syntax Protocols

Proposal: SE-NNNN <>
Author: Matthew Johnson <https://github.com/anandabits&gt;
Status: Awaiting review
Review manager: TBD
Introduction

This proposal renames the *LiteralConvertible protocols to Syntax.*Literal.

Swift-evolution thread: Revisiting SE–0041 Names <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21290&gt;
Motivation

The standard library currently has protocols that use the term Convertible in two different ways. The *LiteralConvertible protocols use the meaning of converting from a literal. The Custom(Debug)StringConvertible protocols use the meaning of converting to a String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.

Further, the standard library team has observed:

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)
An earlier proposal <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt; was intended to address the first problem by introducing strong naming conventions for three kinds of conversion protocols (from, to, and bidirectional). The review highlighted the difficulity in establishing conventions that everyone is happy with. This proposal takes a different approach to solving the problem that originally inspired that proposal while also solving the awkwardness of the current names described by the standard library team.

Proposed solution

This proposal addresses both problems by introducing a Syntax “namespace” and moving the *LiteralConvertible protocols into that “namespace” while also renaming them. The proposal does not make any changes to the requirements of the protocols.

Detailed design

All of the *LiteralConvertible protocols will receive new *Literal names inside a Syntaxnamespace.

This namespace will initially be implemented using a case-less enum, but this detail may change in the future if submodules or namespaces are added to Swift. Swift does not currently allow protocols to be declared inside the scope of a type. In order to work around this limitation the protocols themselves will be declared using underscore-prefixed names internal to the standard library. Typealiases inside the Syntax enum will declare the names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All requirements of all *LiteralConvertible protocols will remain exactly the same.

The following protocol declarations and names:

public protocol NilLiteralConvertible { ... }
public protocol BooleanLiteralConvertible { ... }
public protocol FloatLiteralConvertible { ... }
public protocol IntegerLiteralConvertible { ... }
public protocol UnicodeScalarLiteralConvertible { ... }
public protocol ExtendedGraphemeClusterConvertible { ... }
public protocol StringLiteralLiteralConvertible { ... }
public protocol StringInterpolationLiteralConvertible { ... }
public protocol ArrayLiteralConvertible { ... }
public protocol DictionaryLiteralConvertible { ... }
Are changed as follows:

public protocol _NilLiteralSyntax { ... }
public protocol _BooleanLiteralSyntax { ... }
public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... }
public protocol _UnicodeScalarLiteralSyntax { ... }
public protocol _ExtendedGraphemeClusterLiteralSyntax { ... }
public protocol _StringLiteralLiteralSyntax { ... }
public protocol _StringInterpolationLiteralSyntax { ... }
public protocol _ArrayLiteralSyntax { ... }
public protocol _DictionaryLiteralSyntax { ... }

public /* closed */ enum Syntax {
  public typealias NilLiteral = _NilLiteralSyntax
  public typealias BooleanLiteral = _BooleanLiteralSyntax
  public typealias IntegerLiteral = _IntegerLiteralSyntax
  public typealias FloatLiteral = _FloatLiteralSyntax
  public typealias UnicodeScalarLiteral = _UnicodeScalarLiteralSyntax
  public typealias ExtendedGraphemeClusterLiteral = _ExtendedGraphemeClusterLiteralSyntax
  public typealias StringLiteralLiteral = _StringLiteralLiteralSyntax
  public typealias StringInterplolationLiteral = _StringInterpolationLiteralSyntax
  public typealias ArrayrLiteral = _ArrayLiteralSyntax
  public typealias DictionaryLiteral = _DictionaryLiteralSyntax
}
Impact on existing code

All code that references any of the *LiteralConvertible protocols will need to be modified to reference the protocol via the new Syntax.*Literal name.

Alternatives considered

Protocol names

Several commenters have suggested that the names in this proposal are confusing at the site of use:

struct Foo: Syntax.IntegerLiteral { ... }
One alternative naming scheme would emphasize the semantic of initializing the type with a literal:

struct Foo: Syntax.IntegerLiteralInitializable { ... }
Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged. The core team should feel free to make a final decision on the exact naming scheme used if they choose to accept this proposal.

Previous proposal

This proposal is a follow up to Updating Protocol Naming Conventions for Conversions <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md&gt;\. Many related alternatives were explored during the discussion and review of that proposal.

Acknowledgements

The design described in this proposal was suggested by Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev.

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

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