On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution < [email protected]> wrote:
> > 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. > 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 ( > [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]) > 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]> 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]) > 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] > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
