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
> <[email protected]> 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
> <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>
> 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 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>.
> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
