> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution > <[email protected]> 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. > extension Array: Literal.ArrayProtocol > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 24. Juni 2016 um 17:37:27, Adrian Zubarev ([email protected] > <mailto:[email protected]>) 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 ([email protected] >> <mailto:[email protected]>) 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 >>>> <[email protected] <mailto:[email protected]>> 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 <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 ([email protected] >>>> <mailto:[email protected]>) 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> > > > _______________________________________________ > 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
