[swift-evolution] Fw: Re: [Proposal Draft] Literal Syntax Protocols

[Xiaodi Wu]

On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> That said, how about this design:
>
> public protocol _LiteralNilProtocol { … }
> …
>
> public enum Literal {
>
>     public typealias NilProtocol = …
>     …
> }
>
> I’m pretty sure the standard library team intends to reserve the right to
> use this namespace for other protocols that only exist for syntactic
> support.  This may not always be literals - there may be other kinds of
> syntax supporting protocols in the future.  With that in mind I don’t think
> this design will work.
>

That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both
read very nicely, IMO, so that aspect of the idea is worth considering.


>
> extension Array: Literal.ArrayProtocol
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (
> adrian.zubarev at devandartist.com) schrieb:
>
> Really? I must have overlooked that some pitched that design.
>
> Okay now that I think through this whole scenario, I like the underscore
> iff there is a good name that will be present in the final version.
>
> When Swift 3 drops, I’ll write a proposal for nested protocols which will
> refine your design (the original author went missing after pitching this
> idea, and Joe Groff told me that this probably out of scope for Swift 3)!
>
> Your current design might become this in Swift 3.X and all protocols
> marked with an underscore will disappear:
>
> public /* closed */ enum Syntax {
>   public protocol NilLiteral { ... }
>   public protocol BooleanLiteral { ... }
>   public protocol IntegerLiteral { ... }
>   public protocol FloatLiteral { ... }
>   public protocol UnicodeScalarLiteral { ... }
>   public protocol ExtendedGraphemeClusterLiteral { ... }
>   public protocol StringLiteralLiteral { ... }
>   public protocol StringInterplolationLiteral { ... }
>   public protocol ArrayrLiteral { ... }
>   public protocol DictionaryLiteral { ... }
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew at anandabits.com)
> schrieb:
>
> The design in this proposal comes from the standard library team.  The
> intent is for the use of underscore here to be consistent with other uses
> of underscore prefix in the standard library.  I’m not sure why you think
> this is different than the rest...
>
>
> On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I’m aware of that fact, but all types with underscore even in the stdlib
> telling me to keep my hands of them, because something might happen to them.
> As an example we have _Strideable protocol which is visible by its name,
> but its declaration isn’t visible at all:
>
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598 - should be:
> // protocol Strideable : Comparable {...}
>
> % for Self in ['_Strideable', 'Strideable']:
>
> From Stride.swift.gyb
> <https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew at anandabits.com)
> schrieb:
>
> The underscore is used in the same way it is used elsewhere in the
> standard library.  The protocols must be public because they need to be
> visible to user code in order for the design to work correctly.  However,
> they are considered implementation details that users really shouldn’t know
> about.  This pattern is well established in the standard library.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/d28802f0/attachment.html>