<div dir="ltr">That makes sense, thanks for pointing out a possibility I missed!<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 11:34 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"><span class="">On 14.05.2016 21:20, Austin Zheng wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, this is theoretically possible, but why is it useful? (I am genuinely<br>
curious.)<br>
</blockquote>
<br></span>
I just showing that we *can* invent the situation when checking for struct<Struct,Protocol> have a sense. Not more, not less.<br>
I'm not going to discuss if that can have any (or never can have at all) useful intention.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
If the intention is to allow B to be a user-defined extension point for T,<br>
this goes back to the core team's arguments (in the thread about optional<br>
protocol requirements) about why having checking for conformance to some<br>
requirement at the use site is a suboptimal idea.<br>
<br>
If the intention is to make the type system as expressive as possible, the<br>
core team has already ruled out a number of features (user-defined variance<br>
on generics, generic protocols) because they don't believe in their general<br>
applicability.<br>
<br>
Austin<br>
<br>
On Sat, May 14, 2016 at 11:13 AM, Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>>> wrote:<br>
<br>
FWIW, yes, protocols available for struct are known at compile-time,<br>
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{..}<br>
<br>
<br>
<br>
<br>
On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:<br>
<br>
1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the<br>
struct<...> representation is unnecessary; the protocols that are<br>
available<br>
to the user are known at compile-time, and structs can't have<br>
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<br>
ways to<br>
express the same idea makes the language better, easier to use, etc.<br>
<br>
<br>
</span></blockquote>
</blockquote></div><br></div>