what about `*LiteralRepresentable`?
On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution <
[email protected]> 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 <
> [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. 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 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>.
> 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
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
