What an disturbing name... 'Syntax.xxx' it makes me anticipate basically a proliferation of other: NarrowLittleCornerCase.yyyy YetAnotherNameToIsolateSomethingElseFromTheRest.zzzz
It evokes to me the "File file" naming pattern (compared to 'File settings' or 'File avatarImage') Regards LM (From mobile) > On Jun 23, 2016, at 5:31 PM, 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
