Hmm..
What about such synthetic scenario:
at the moment of writing our code we have:
public protocol MyProtocol {
func foo()
}
public struct StructA:MyProtocol {
func foo()
}
public struct StructB:MyProtocol {
func foo()
}
and have
public protocol ExtraProtocol1 {
func bar()
}
public protocol ExtraProtocol2 {
func blort()
}
then we actually can have such code:
func f(p: MyProtocol) {
if let a = p as? struct<StructA, ExtraProtocol1> {
a.foo()
a.bar()
}
else
if let b = p as? struct<StructB, ExtraProtocol2> {
b.foo()
b.blort()
}
}
as we can(as example) expect that in 3rd party code someone will do:
extension StructA: ExtraProtocol1 {
func bar() {}
}
extension StructB: ExtraProtocol2 {
func blort() {}
}
On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
'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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
