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