That makes sense, thanks for pointing out a possibility I missed! Austin
On Sat, May 14, 2016 at 11:34 AM, Vladimir.S <sva...@gmail.com> wrote: > On 14.05.2016 21:20, Austin Zheng wrote: > >> Yes, this is theoretically possible, but why is it useful? (I am genuinely >> curious.) >> > > I just showing that we *can* invent the situation when checking for > struct<Struct,Protocol> have a sense. Not more, not less. > I'm not going to discuss if that can have any (or never can have at all) > useful intention. > > >> 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. >> >> 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. >> >> Austin >> >> On Sat, May 14, 2016 at 11:13 AM, Vladimir.S <sva...@gmail.com >> <mailto:sva...@gmail.com>> wrote: >> >> 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
