'struct<>' does seem redundant unless it becomes subtypeable. If you want a
struct which conforms to several protocols, protocol<> already covers this.
I think this is not correct. Lets check this example:
func foo(value: SomeProtocol) {
if let a = value as? struct<StructA, SomeProtocol> { /* do something with a
*/ }
else if let b = value as? struct<StructB, SomeProtocol> { /* do something
with b */ }
}
In this scenario you’ll be able to access properties and functions from
`StructA` or `StructB` which might not be covered by `SomeProtocol`. Everything
is merged nicely into one instance. But you are right it depends on the
use-case.
There is no need to include the protocol here. Just do this:
if let a = value as? StructA { use a }
Whoops, I forgot that this will do the trick. I apologize for any confusion
here, you are totally right.
That been said, do we really need `type<>` aka. `all<>` for value types? I need
to rethink this part of the proposal. Is there any use-case where we would need
this (any scenario for the future Swift version also counts)?
If we had `all<>` in Swift already for extendable reference types and one day
structs would become subtypeable, this wouldn’t be a huge problem to upgrade
`all<>` for structs I guess.
--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
