> On Jun 23, 2016, at 12:26 PM, David Sweeris <[email protected]> wrote: > > +1 > > “Syntax” still feels weird, though… > > Oh, so if the idea is that literals don’t have a type, that the “Syntax” > isn’t meant to be exclusively about literals, and that the various > `*LiteralConvertible` protocols only exist to tell the -->compiler<-- what > types any given literal can become, what about just calling it “Compiler”? > struct Foo : Compiler.IntegerLiteral {} > > This reinforces the notion (at least in my mind, and at least more than > “Syntax” does) that literals live outside of Swift’s "normal" type system.
Thanks for the feedback. `Compiler` seems like a reasonable alternative. I will add it to the proposal. I anticipate plenty of bike shedding during discussion / review and want to encourage the community to debate the pros and cons of the options we are able to come up with. > > - Dave Sweeris > >> On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
