> On Jun 23, 2016, at 11:43 AM, Nate Cook <[email protected]> wrote: > > I like the namespace-based approach to group these protocols together and I'm > very happy to see some clarification happening in this group of protocols. > However, I don't think the proposed new names communicate what they need to. > The names listed in the "Alternatives Considered" section do a better job of > describing the use and behavior of these protocols. > > Primarily, the new names read like we're saying that a conforming type is a > literal, compounding a common existing confusion between literals and types > that can be initialized with a literal. Swift's type inference can sometimes > make it seem like dark magic is afoot with literal conversions—for example, > you need to understand an awful lot about the standard library to figure out > why line 1 works here but not line 2: > > var x = [1, 2, 3, 4, 5] > let y = [10, 20] > > x[1..<2] = [10, 20] // 1 > x[1..<2] = y // 2 > > These new names are a (small) step in the wrong direction. While it's true > that the type system doesn't have an IntegerLiteral type, the language does > have integer literals. If someone reads: > > extension MyInt : Syntax.IntegerLiteral { ... } > > the implication is that MyInt is an integer literal, and therefore instances > of MyInt should be usable wherever an integer literal is usable. The existing > "Convertible" wording may be a red herring, but it at least suggests that > there's a difference between a literal and a concrete type. > > In sum, I support a change like this and strongly recommend keeping some sort > of adjective in the protocol name.
I appreciate your comments Nate. Do you mind if I paste some of this into the proposal in the alternatives considered section? I tend to agree with this and prefer the `Syntax.*LiteralInitializable` names myself. However, the standard library team seems to prefer the names in the proposal. I have already had a related proposal rejected because the core team didn’t like the names in the proposal so I am taking a conservative approach here of writing the proposal using the names they prefer and listing my preference as an alternative. I am hoping community feedback will prompt the core team to accept a revised version with names that are a bit more clear. Short of that, I am hoping to avoid rejection as I think the proposal as-written is an improvement over current state. > > Nate > > >> 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
