[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution
plxswift at icloud.com
Sun Feb 14 12:49:43 CST 2016
> 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’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
>> 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,
> 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 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,
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> 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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution