[swift-evolution] [Pitch] Require Any for existentials

[Vladimir.S]

On 24.08.2016 13:23, Haravikk via swift-evolution wrote:
>
>> On 23 Aug 2016, at 23:14, Adrian Zubarev via swift-evolution
>> <swift-evolution at swift.org> 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 swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>