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

Dave Abrahams dabrahams at apple.com
Thu Feb 11 17:17:10 CST 2016 

on Thu Feb 11 2016, Jarod Long <swift-AT-lng.la> wrote:

>> On Feb 11, 2016, at 14:40, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Thu Feb 11 2016, Jarod Long <swift-AT-lng.la> wrote:
>> 
>
>>> Here are some thoughts after having quietly pondered the mutating method naming discussion for a while.
>>> 
>>> My view is that an "ed/ing" mutation rule is fraught with undesirable
>>> compromises. It's tempting because it works so well in the majority of
>>> cases, but it seems that cases where it doesn't work are not uncommon,
>>> even when the scope of the discussion is narrowed to a small set of
>>> operations such as this. We're trying to play nice with English, but
>>> we're butting up against its fundamental lack of clarity.
>>> 
>>> As far as I see it, these are the options (forgive me for repeating
>>> much of what others have said -- I'd like to accurately convey my
>>> perception of the situation as a whole):
>>> 
>>> 1. Move forward with ed/ing-based guidelines that work well in many
>>> cases. For the cases which don't work well, we can either:
>>> 
>>> Have explicit exceptions, likely leading to overly-complicated guidelines that people may not be bothered to follow.
>>> Leave it up to the developer to decide what's best on a case-by-case
>>> basis, likely leading to inconsistencies and lots of time spent on
>>> discussions of this magnitude.
>>> 
>>> There's also a worrying amount of uncertainty and subjectivity
>>> involved in identifying the situations where the base guidelines don't
>>> work well, particularly for developers who aren't experts in English.
>> 
>> It looks like we are poised to:
>> 
>> * Force Set into the mold by “verbing” nouns as noted in the beginning
>>  of the thread, because it's a prominent type and it should follow the
>>  main guideline.
>> 
>> * “Punt” on the more general question of what to do about other cases
>>  that don't fit well.  That is, we'll make a decision later.  In the
>>  meantime it would be great if the community would gather a list of
>>  problematic cases.  There is some starter material in
>>  https://gist.github.com/dabrahams/847cf573f8795fc07596
>> <https://gist.github.com/dabrahams/847cf573f8795fc07596> if it
>> helps.
>> 
>>> 2. Use "inPlace" or some other simple adornment that can be universally applied to a method without exceptions.
>>> 
>>> An inPlace suffix would be a significant eyesore for such a common
>>> pattern. There doesn't seem to be another less obtrusive suffix that
>>> properly conveys mutation, so we're either stuck with inPlace, or we
>>> could try to find a more terse symbolic pattern (the same idea as
>>> Ruby's postfix ! to indicate mutation). Nothing desirable comes to
>>> mind, though.
>> 
>> Others have suggested the "form" prefix:
>> 
>>       x.formUnion(with: y)
>> 
>>> 3. Add a language-level feature that allows a method on a type which
>>> returns a value of that same type to be called in a way that mutates
>>> the callee.
>>> 
>>> Even when naming isn't an issue, defining mutating / non-mutating
>>> versions of method is somewhat tedious and inflates the type's
>>> interface. Any method that returns a value of the callee's type is a
>>> valid candidate for a mutating version of that API, but defining the
>>> mutating version is 100% boilerplate.
>>> 
>>> Support from the compiler would eliminate this boilerplate as well as
>>> this seemingly-unsolvable naming problem at the cost of some
>>> additional complexity in the compiler.
>>> 
>>> I can see two options off the top of my head. First, a method that
>>> returns the same type as the callee mutates when its return value is
>>> unused instead of producing a warning:
>>> 
>>> let c = a.union(with: b) // Doesn't mutate.
>>> a.union(with: b)         // Mutates.
>>> 
>>> This is somewhat subtle and has some potential for confusion, but I
>>> think Swift's strong immutability features would make it extremely
>>> rare for this pattern to create bugs.
>>> 
>>> Or, we can create a special syntax for mutating a callee with the return value of its method:
>>> 
>>> a .= union(with: b) // First thing that comes to mind. It's
>>> conceptually similar to += and friends and makes assignment explicit.
>> 
>> I suppose you haven't seen
>> https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst
>> <https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst>
>> already?
>
> I sure haven't! Now I feel a little silly for typing all this up, but
> I'm glad this is something being considered for the future. If we're
> reasonably confident that something like this will end up in Swift one
> day, then I'm much less concerned about making the naming guidelines
> work perfectly for every use case in the mean time.

For the record, I do not feel at all confident anything like this will
end up in swift.  This feature was proposed back in 2013, before Swift
was released, eventually accepted then not implemented because we were
out of time, then revised, then re-accepted and implemented, then ripped
out of the compiler because of various concerns about what it does to
the shape of the language (e.g. is this just a second version of
“mutating?”  What about classes?).  Based on history, I don't think it's
a sure bet, and I personally may be out of energy and time to fight for
it.  But we'll have to see...

> Thanks for your patience in my overlooking things that have already
> been discussed.
>
>>> a = .union(with: b) // Similar idea, looks less like you're calling a
>>> global method called union.
>>> 
>>> My personal preference lies strongly in option 3 with roughly equal
>>> preference for either sub-option, but I'd really like to hear what
>>> others think.
>>> 
>>> Jarod
>>> 
>>>> On Feb 11, 2016, at 11:43, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Just thinking out loud here:
>>>> 
>>>> "x's intersection with y" makes sense. So "x.intersection(with: y)" makes sense.  That's already in Dave's diff.
>>>> 
>>>> Unfortunately the same doesn't work well for "x's union with y" —
>>>> should "x.union(with: y)" be a mutating or nonmutating operation?
>>>> Hard to tell.
>>>> 
>>>> How about we just move to ∪ and ∪= operators and call it a day? :-)
>>>> 
>>>> On Thu, Feb 11, 2016 at 11:36 AM, Erica Sadun
>>>> <erica at ericasadun.com <mailto:erica at ericasadun.com>
>>>> <mailto:erica at ericasadun.com <mailto:erica at ericasadun.com>>>
>>>> wrote:
>>>> Assuming one would want to avoid the -ed suffix (and also -ing), one might consider:
>>>> 
>>>> * intersectionOf(), orOf(), unionOf() (or "With" over "Of")
>>>> * setIntersection(), setOr(), setUnion(),
>>>> * intersectionResult(), orResult(), unionResult(),
>>>> etc
>>>> 
>>>> -- E
>>>> 
>>>> 
>>>>> On Feb 11, 2016, at 12:28 PM, Jacob Bandes-Storch
>>>>> <jtbandes at gmail.com <mailto:jtbandes at gmail.com>
>>>>> <mailto:jtbandes at gmail.com <mailto:jtbandes at gmail.com>>> wrote:
>>>>> 
>>>>> "intersected" sounds okay to me. "unioned" is borderline, and
>>>>> "ored" is not something I'd want in the standard library. Neither
>>>>> is "oring".
>>>>> 
>>>>> On Thu, Feb 11, 2016 at 11:25 AM, Erica Sadun
>>>>> <erica at ericasadun.com <mailto:erica at ericasadun.com>
>>>>> <mailto:erica at ericasadun.com <mailto:erica at ericasadun.com>>>
>>>>> wrote:
>>>>> I see the -ed versions as short for -edSet, with the Set being
>>>>> implied. Under this reasoning, unioned == unionedSet, intersected
>>>>> == intersectedSet, thus acting as nouns not verbs, and used for
>>>>> non-mutating application.
>>>>> 
>>>>> inPlace is only for mutating application. I mildly prefer the
>>>>> shorter union to unionInPlace, although I could argue both
>>>>> sides. (The latter is clearer but longer, the former is the short
>>>>> verb action that the whole guideline thing is supposed to endorse.)
>>>>> 
>>>>> -- E
>>>>> 
>>>>>> On Feb 11, 2016, at 12:19 PM, Jacob Bandes-Storch
>>>>>> <jtbandes at gmail.com <mailto:jtbandes at gmail.com>
>>>>>> <mailto:jtbandes at gmail.com <mailto:jtbandes at gmail.com>>> wrote:
>>>>>> 
>>>>>> On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution
>>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> <mailto:swift-evolution at swift.org
>>>>>> <mailto:swift-evolution at swift.org>>>
>>>>>> wrote:
>>>>>> Non-Mutating, returning new value: unioned(with), intersected(with), exclusiveOred(with)
>>>>>> 
>>>>>> Reasoning:
>>>>>> 
>>>>>> * I think the -ing endings sound unnatural, stilted, and unmathematical. They make me wince.
>>>>>> 
>>>>>> So do the -ed versions, IMO. That's why -InPlace is such a convenient suffix.
>>>>>> 
>>>>>> Jacob
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>

-- 
-Dave

More information about the swift-evolution mailing list