[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution
Dave Abrahams
dabrahams at apple.com
Sun Feb 14 10:29:52 CST 2016
on Sun Feb 14 2016, Daniel Steinberg <daniel-AT-dimsumthinking.com> wrote:
> I was a fan of the inPlace variants because for me it was more clear
> than remembering sort from sorted.
>
> Is there a reason for the mutating versions of these at all?
Efficiency.
> I would say that setA = setA.union(setB) is most expressive of
> intent. It makes it absolutely clear that setA is being replaced by
> something.
>
> Having a mutating or non-mutating version of an operation but not both
> would be less confusing IMO.
>
> Methods such as append() and remove() could still be mutating as there
> has never been non-mutating version of them. Or the suggested .=
> operator could be used and all of these methods could become
> non-mutating.
>
> i.e.
>
> setA .= union(setB)
>
> arrayC .= elementToAdd
>
> arrayD .= removeAll()
>
> where A .= method() means A = A.method()
As noted elsewhere, language features to help solve this are
out-of-scope—at least for the time being and quite possibly forever. We
need to handle it with naming conventions in the here and now.
> Daniel
>
>> On Feb 13, 2016, at 2: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.
>>
>>> 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.
>>
>>> 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.
>>
>>>> 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
>>> 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>
--
-Dave
More information about the swift-evolution
mailing list