Okay I must correct myself. This wouldn’t work if it was a module, nested types behave differently. I’m sorry for any confusion.
-- Adrian Zubarev Sent with Airmail Am 29. Juni 2016 um 17:32:46, Adrian Zubarev ([email protected]) schrieb: By the way, what we’ve not have discussed here yet is if we want to use this new protocols like this: extension SomeType : ArrayProtocol { … } Or extension SomeType : Syntax.Literal.ArrayProtocol { … } Closed enums will allow us to use ArrayProtocol where groups won’t. Just wanted to add this to the conversation. -- Adrian Zubarev Sent with Airmail Am 29. Juni 2016 um 17:10:10, Adrian Zubarev ([email protected]) schrieb: Since bikeshedding ideas in here abusing a closed enum anyway I’d like to share my vision of this proposal in a future release with pitched group mechanism (proposal link) and nested protocols in mind: public group Syntax { // No need for `public` because groups inherit // the access modifier from its root group group Literal { // no need for `public` here, because all group members // will have the access modifier specified by the group protocol NilProtocol { ... } protocol BooleanProtocol { ... } protocol IntegerProtocol { ... } protocol FloatProtocol { ... } protocol UnicodeScalarProtocol { ... } protocol ExtendedGraphemeClusterProtocol { ... } protocol StringProtocol { ... } protocol StringInterpolationProtocol { ... } protocol ArrayProtocol { ... } protocol DictionaryProtocol { ... } } } Changing my first example of Syntax.Literal.*Protocol to this design won’t even break. :) -- Adrian Zubarev Sent with Airmail Am 29. Juni 2016 um 16:55:10, Matthew Johnson ([email protected]) schrieb: On Jun 29, 2016, at 9:46 AM, Adrian Zubarev via swift-evolution <[email protected]> wrote: I wouldn’t use the Type suffix, because I believe this will create even more confusion with the associatedtype IntegerLiteralType from the current IntegerLiteralConvertible itself. Thanks for pointing this out! I wasn’t thinking about the associated type names. We definitely would not want the protocol and the associated type to have the same name. Of course we *could* open the door to renaming the associated type requirements to something like `IntegerLiteralParameterType` if we decide that `Syntax.*LiteralType` is the best naming convention for the protocols. I’m not necessarily advocating for this idea, but wanted to share it since there is very active bikeshedding happening right now. My plan is to stay neutral on the naming and let the community and core team decide what is best. -- Adrian Zubarev Sent with Airmail Am 29. Juni 2016 um 16:42:02, Matthew Johnson ([email protected]) schrieb: On Jun 29, 2016, at 9:15 AM, Erica Sadun via swift-evolution <[email protected]> wrote: I rather like this one. It produces: `Syntax.Literal.IntegerProtocol`, which is honestly the best I've seen so far *and* it might get past the Dave test. I’m curious to see what Dave thinks of this as well. `Syntax.IntegerLiteralType` is another that popped into my mind this morning. I don’t recall if that has been mentioned yet. The idea here is that an integer literal *can be typed as* a type that conforms to this protocol (the type suffix *is not* used in the sense that it used to be used in things like `SequenceType` which had the semantic that conforming types *are* sequences). -Matthew Thank you for bringing this into the conversation! -- E On Jun 29, 2016, at 12:31 AM, Adrian Zubarev via swift-evolution <[email protected]> wrote: How about: public enum Syntax { public enum Literal { public typealias NilProtocol = ... public typealias BooleanProtocol = ... public typealias IntegerProtocol = ... public typealias FloatProtocol = ... public typealias UnicodeScalarProtocol = ... public typealias ExtendedGraphemeClusterProtocol = ... public typealias StringProtocol = ... public typealias StringInterpolationProtocol = ... public typealias ArrayProtocol = ... public typealias DictionaryProtocol = ... } } extension Array : Syntax.Literal.ArrayProtocol { ... } _______________________________________________ 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
