[swift-dev] Should we remove _customContainsEquatableElement from stdlib?

[Ling Wang]

Got it. `contains` is only declared in extension. Interesting workaround. Thanks.

> On Dec 30, 2015, at 4:45 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev
> <swift-dev at swift.org> wrote:
>> After reviewing the code of stdlib I found no one actually implements _customContainsEquatableElement:
>> 1. Its default implementation in `SequenceType` just returns nil.
>> 2. The implementation in `Set` delegates to `contains` which is bad because it reverses their relationship: the default implementation of `contains` in `SequenceType` delegates to `_customContainsEquatableElement`.
>> 3. In all other place it just delegates to another `SequenceType`.
>> 
>> So no one is doing real work.
>> 
>> If the current _customContainsEquatableElement is only a relic I suggest we remove it and clean up related code.
> 
> It is not a relic.  It allows the contains() method to perform dynamic
> dispatch in case the container knows something extra about the
> elements.
> 
> Consider the case when you have a Set typed as a plain Sequence or a
> Collection.  In that case, you won't be able to call the custom
> Set.contains() method, the overload resolution will only see the
> protocol extension.  This extra entry point,
> _customContainsEquatableElement, allows us to perform dynamic dispatch
> and use the fast Set implementation if it is available.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/