[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 7:31 PM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> on Thu Feb 11 2016, Jarod Long <swift-evolution at swift.org> wrote:
>>
>>>> On Feb 11, 2016, at 15:20, Erica Sadun <erica at ericasadun.com> wrote:
>>>>
>
>>>>> On Feb 11, 2016, at 4:17 PM, Dave Abrahams
>>>>> <dabrahams at apple.com
>>>>> <mailto:dabrahams at apple.com>> wrote:
>>>
>>>>>
>>>>> 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...
>>>>>
>>>
>>> Interesting -- I wasn't aware of the history of the proposal. I would
>>> be very interested in revisiting it to get the consideration of the
>>> larger Swift community. Is this something that would be reasonable in
>>> the Swift 3 timeframe, or should this wait until we can discuss Swift
>>> 4?
>>
>> Realistically, I think that proposal cannot be considered for Swift 3.
>
> Understandable. FWIW, if one believes in autocomplete, superscript
> equal sign is already a valid identifier head character (per
> documentation and experimentation in a playground). So, if the gist of
> the proposal is acceptable, one can already name a pair of functions
> union() and union=() if the "=" is replaced with its superscript (and
> for that matter, =union(), but autocomplete might not help with that
> one). 

Hmm, use the fullwidth equal sign; it reads better, and compiles:

  mutating func ＝union(other: Self) { ... }

Heh, that is awesome; we could do some real fun proofs-of-concept for
the proposal using that trick.  The autocomplete problem can/should be
fixed by tooling.

> Not sure this idea will gain too much traction, but if the union
> operator ∪ is being thrown out as a possibility, I thought I'd put it
> out there.

I think the biggest obstacle to the operator ∪ by itself is that it's
hard to type, and autocomplete doesn't have any ordinary ASCII
characters to work with.  At least with ＝union, “u n i<TAB>” could be
made to find it.

> In terms of symbols easily accessible on the keyboard not reserved for
> operators, Xcode doesn't seem to complain about a function named
> union$(), but that is a pretty bizarre-looking function name. More
> horrifying than unioning() though?

Eye of the beholder, apparently.

-- 
-Dave