Fair enough. But in that case I think we want something that does exactly
that: rejects classes, rather than indicating value semantics. We need to do
this in a way that doesn’t lead to a situation where we used the word `value`
to mean “value type”, and later we have the capability to very value semantics
and really wish `value` could mean value semantics but that would be a breaking
change we aren’t willing to make.
Exactly, `any<class>` is just a constraint that indicates which type it can
hold, where `any<struct>` or `any<enum>` are two constraints and (not yet
existing) counterparts to `any<class>`.
The idea behind `any<struct>` (or `any<enum>`) might look like this:
func foo(struct: any<struct, SomeProtocol>)
Where it is clear that you have to provide a custom struct which conforms to
`SomeProtocol`, you’re not constrained to just a single struct, you can build
as many as you want it it’s your desire. :)
Lets just imagine we already have `any<…>` and we also get `oneOf<…>` or
`one<…>` which picks only one constraint at compile time and proceeds.
Here is what you could do for extendable types:
typealias AnyValue = one<any<struct>, any<enum>>
func boo(value: any<AnyValue, SomeProtocol>)
Not sure if we’ll get there or not but its a nice imagination. :)
I’m not exactly in favor of using `any<class>` instead of AnyClass but I’m
openminded. :)
One problem to solve is the conformance to protocols:
If we’ll get `any<…>` and depricate `AnyClass` `AnyObject` we cannot do this
directly:
protocol A: any<class> {}
protocol B: any<ProtocolX, ProtocolY>
We still need a typealias as a workaround:
typealias AnyClass = any<class>
typealias AnyXY = any<ProtocolX, ProtocolY>
protocol A: AnyClass {} furthermore is this protocol equivalent to protocol A:
class {} ???
protocol B: AnyXY {}
--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
