> On Jun 24, 2016, at 3:06 PM, Xiaodi Wu <[email protected]> wrote: > > > > On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution >> <[email protected] <mailto:[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. > > That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both > read very nicely, IMO, so that aspect of the idea is worth considering.
Yes, I have incorporated these into the alternatives section of the proposal. I appreciate your suggestions! I’ll be submitting a PR later today or tomorrow if no significant new feedback arises. > > >> 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 <> - 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] <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] <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
