[swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Vladimir.S]

+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>
>   * 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>
>
>
>     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> 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>.
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>