On 24.08.2016 13:23, Haravikk via swift-evolution wrote:
On 23 Aug 2016, at 23:14, Adrian Zubarev via swift-evolution
<[email protected]> wrote:
The basic design is fine, but I wouldn't want to add more noise to my
code. We could keep (label: Protocol) as a shorthand form for (label:
Any<Protocol>) similar to Optionals.
What's the benifite of this anywasys? What exactly will this solve?!
Currently we can only use a protocol as if it were a type when it has no
associated types, existentials will eliminate that restriction, allowing
us to use a protocol Foo where we would currently either have to use
AnyFoo or a very verbose generic constraint. I think the point of this
proposal is to ask whether we should be able to use protocols as if they
were concrete types, or whether it would be better to require Any<> to
clarify what's really happening.
I believe Any<> could remove some inconsistency/confusion when protocol is
used as generic constraint in 'where' clause. Let's see:
we can have such function:
func process<T: Sequence>(_ seq: T) where T.Iterator.Element == MyElement
and we can have such :
func process<T: Sequence>(_ seq: T) where T.Iterator.Element : MyElement
the first will accept array only if typed as [MyElement] i.e.
let arr : [MyElement] = ...
, it is logical as constraint defined with '==' i.e. type is strictly equal.
but the second form will not allow you to use instance typed as [MyElement]
or as any derived protocol like [ProtocolDerivedFromMyElement] - although
one can expect this in analogue with class/value type in constraint - but
will accept array *typed* as class/struct conformed to MyElement protocol,
i.e.
struct S: MyElement {..}
let arr : [S] = ...
In case we'll have Any<>, the second definition as I understand should
looks like:
func process<T: Sequence>(_ seq: T) where T.Iterator.Element : Any<MyElement>
i.e. in this case it clearly show that it will accept array(sequence) typed
as some concrete type conformed to protocol.
Personally I'm on the fence; I don't particularly mind being able to use
a protocol name as if it were a concrete type, but I do generally prefer
for things to be explicit wherever confusion may be caused. I think that
requiring Any<> could be a good thing, as it clarifies that what you're
interacting with is not a concrete type, and highlights that it may
optimise differently (I'm not 100% on the details of how existentials
actually work).
So I'd say I'm a tentative +0.5; in terms of migration I don't think
this is all that source breaking, as it's very easy to add a fixit for
(possibly even an automatic one?) and it only currently applies to
non-generic protocols anyway, which seems relatively niche.
_______________________________________________ swift-evolution mailing
list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
