+1 from me. If I'll see `struct A : Syntax.NilLiteral {..}` I read this as
"`A` could be represented in syntax as nil literal" or even "A could be a
nil literal in syntax"
On 23.06.2016 18:31, Matthew Johnson via swift-evolution 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 <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 |Syntax|namespace.
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]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
