Sent from my iPad
> On Jun 23, 2016, at 10:39 AM, Sean Heber <[email protected]> wrote: > > 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. > > 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 >> <[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 >> • 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
