[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution

[Dave Abrahams]

on Sun Feb 14 2016, plx <swift-evolution at swift.org> wrote:

>> On Feb 13, 2016, at 1:32 PM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Sat Feb 13 2016, plx
>
>> <swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On a skim, if there’s a specific explanation as to *why* `inPlace` is
>>> a now a no-go, I don’t see it. 
>> 
>> Several justifications were given:
>> 
>> * Several people have an “ick” reaction when they see it.
>> 
>> * It's not in the guidelines.
>> 
>> * If we add it to the guidelines, it will only be as fallback
>>  last-resort alternative.
>> 
>> * If one of the three main collection types can't conform to the
>>  recommendations of the non-last-resort guidelines, the guidelines are
>>  a failure.
>
> As a devil’s advocate, why wouldn’t the existing names be justifiable
> under “Use terminology well” guideline?

I'm afraid you'll have to ask someone who understands the decision :-).
I've asked someone else to explain it; hopefully that will happen soon.

> I’d consider making up new terminology for a well-established domain
> much worse than simply not following the naming conventions.
>
>> 
>>> I can’t say I like the proposed changes
>>> very much, and I definitely don’t like some of the more-creative
>>> suggestions.
>>> 
>>> It’s hard to offer help when it’s not clear what was deemed
>>> problematic about the existing (and “perfectly fine with me”!) names.
>>> 
>>> Separately, can I ask here why SetAlgebra protocol doesn’t contain an
>>> *overridable* method like `func intersects(other: Self) -> Bool`?
>>> 
>>> (Note: I am *well-aware* that `a intersects b <=> !(a and b are disjoint)`).
>> 
>> There's no point in providing an override if there's no chance of it
>> being better than the default implementation.
>
> But again, cf `isSupersetOf` and `isSubsetOf`...which are both
> overridable unless I’m misunderstanding. (Especially as there’s risk
> of a performance “gotcha” if you only override “the wrong one”).
>
>> 
>>> That absence has been puzzling me ever whichever release of Swift
>>> first introduced this protocol, particularly since e.g. both
>>> `isSubsetOf` and `isSupersetOf` are individually-overridable.
>>> 
>>> (Likewise, but less so, I do wonder why the protocol doesn’t contain
>>> *overridable* `isStrictSubset` and `isStrictSuperset` functions,
>>> either...).
>> 
>> Same reasoning, but we may have mistakenly decided there was no chance
>> of optimization.  If so, please open a ticket.
>
> There are definitely examples of such; https://bugs.swift.org/browse/SR-735 . 
>
> After looking at what’s in github, there really ought to be a few more
> families of default implementations, e.g. `extension SetAlgebraType
> where Self:CollectionType` and `extension SetAlgebraType where
> Self:CollectionType, Index: RandomAccessIndexType` (where we can
> assume O(1) count).
>
> Is that better as just a ticket or as a discussion on one of the
> lists?

On the surface they seem like clear bugs/missed optimizations to me, so
I think tickets are the right medium.

>
>
>> 
>>>> On Feb 11, 2016, at 10:52 AM, Dave Abrahams via swift-evolution
>>>> <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> Hi All,
>>>> 
>>>> The API guidelines working group took up the issue of the InPlace suffix
>>>> yesterday, and decided that it was not to be used anywhere in the
>>>> standard library.  We are planning to apply the changes shown here
>>>> <https://gist.github.com/dabrahams/d872556291a3cb797bd5> to the API of
>>>> SetAlgebra (and consequently Set) to make it conform to the guidelines
>>>> under development.
>>>> 
>>>> Comments welcome as usual,
>>>> 
>>>> -- 
>>>> -Dave
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave