<div dir="ltr">Yes, this is theoretically possible, but why is it useful? (I am genuinely curious.) <div><br></div><div>If the intention is to allow B to be a user-defined extension point for T, this goes back to the core team's arguments (in the thread about optional protocol requirements) about why having checking for conformance to some requirement at the use site is a suboptimal idea.</div><div><br></div><div>If the intention is to make the type system as expressive as possible, the core team has already ruled out a number of features (user-defined variance on generics, generic protocols) because they don't believe in their general applicability.</div><div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 11:13 AM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, yes, protocols available for struct are known at compile-time, but could be unknown at the *moment of writing* the code.<br>
<br>
What I mean:<br>
<br>
Step 1. I write source code:<br>
<br>
protocol A {}<br>
protocol B {}<br>
struct S:A {}<br>
<br>
func f(a: A) {<br>
if a is struct<S,B> {...} // I expect that S could be conformed to B<br>
}<br>
<br>
Step 2. I give my code to someone, who can do somewhere in his project:<br>
<br>
extension S:B{..}<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the<br>
struct<...> representation is unnecessary; the protocols that are available<br>
to the user are known at compile-time, and structs can't have subtypes that<br>
conform to additional protocols like classes can. There is an example<br>
marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func<br>
boo(value: SomeStruct)"; my question is why having more than two ways to<br>
express the same idea makes the language better, easier to use, etc.<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>