[swift-evolution] [Proposal Draft] Literal Syntax Protocols

Hooman Mehr hooman at mac.com
Sun Jun 26 13:38:40 CDT 2016 

This is already rejected for not being clear enough. We can express some Double values using integer literal syntax, because integers are a subset of floating point numbers but not the other way around. Representable seems to imply it should work both ways.

*LiteralConvertible protocols indicate that we can always use the syntax of the given kind[1] of literal to create an instance of that type. This operation is inherently one way as Literal is a concept that is defined in the context of the source code under compilation. 

Compiler converts a literal (a stream of characters in the source code that adhere to the syntax of a given kind of literal) to an instance of some type. This is where the original Convertible comes from. 

As you see this is all about compiler and language syntax. That is why the new round of suggested names focus on Compiler and Syntax words to keep the domain clear. It is unfortunate that it does not fit the API guidelines protocol naming conventions.

[1] I am avoiding the use of word “type” here to avoid confusion.
 

> On Jun 26, 2016, at 10:06 AM, T.J. Usiyan <griotspeak at gmail.com> wrote:
> 
> what about `*LiteralRepresentable`?
> 
> On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Syntax by itself is not clear enough. Appending Initializable makes it too long. 
> 
> We can replace Syntax with LiteralSyntax to clarify. Then we will have:
> 
> extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ }
> 
> Better yet, to address the valid concern of doing something so different and hack-like for literals, how about simply renaming *LiteralConvertible protocols to *LiteralSyntax or LiteralSyntax*. The key is the LiteralSyntax phrase which (I think) is the clearest short phrase we can get to communicate the intent. Look: It is right there in the title!
> 
>> On Jun 23, 2016, at 8:31 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <>
>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160626/e2d75472/attachment.html>

More information about the swift-evolution mailing list