'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.
Btw, if we'd have separate class<> and struct<> - we'd be able to have method
to separate reference type from value type.
We can write now : print(c is protocol<>)
and we'd can:
print(c is class<>)
print(c is struct<>)
True, I didn’t thought about that effect at the first glance, thank you for the
hint. I will add this to the draft proposal tomorrow.
--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
