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
