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

[Dave Abrahams]

on Thu Feb 11 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Thu, Feb 11, 2016 at 4:40 PM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>> 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 if it helps.
>
> If that's the decision of the core team, then I suppose we'll have to
> live with it. But, FWIW, if you're noting feedback from the community,

we are, thanks.

> 
> my two cents are: (a) Both union()/unionInPlace() and
> unioning()/union() are less than ideal function names, but the former
> is both immediately clear and less 'horrifying' in terms of contorting
> the English language.  (b) It seems that many are willing to live with
> the wording if it's only temporary, but if the long-term roadmap as
> currently envisioned is to take today's union(), turn it into
> unioning(), then turn it back into union(); and to take today's
> unionInPlace(), turn it into union(), then into =union() [and yes, the
> right tooling will mitigate the pain of these transitions to a long
> extent], is making this change as proposed now clearly superior to the
> status quo?  _______________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave