FWIW, yes, protocols available for struct are known at compile-time, but
could be unknown at the *moment of writing* the code.
What I mean:
Step 1. I write source code:
protocol A {}
protocol B {}
struct S:A {}
func f(a: A) {
if a is struct<S,B> {...} // I expect that S could be conformed to B
}
Step 2. I give my code to someone, who can do somewhere in his project:
extension S:B{..}
On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
