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

[Xiaodi Wu]

Darn. Would have been nice. Thanks for explaining why though. Can I
try your patience with another naive question?

Unless the functions also return an error, mutating/non-mutating pairs
of functions return Void/Self (or maybe Optional<Self>) respectively.
Are there other possibilities? But Swift is pretty unique among
C-family languages in allowing overloaded functions that differ only
by return type. Besides the loss of clarity to the reader at the call
site, what are downsides of simply naming both functions exactly the
same in today's Swift syntax?

```
let foo: Foo
// suppose I can call a mutating or non-mutating foo.frobnicate()

let bar = foo.frobnicate() // surely, I must mean the non-mutating form

foo.frobnicate() // I must want to mutate `foo` unless I want only
side effects and an unused result
foo.frobnicate() as Foo // if so, I could always do this
```


On Thu, Feb 11, 2016 at 5:57 PM, Greg Parker <gparker at apple.com> wrote:
>
>> On Feb 11, 2016, at 3:54 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> This is an interesting bit of historical perspective. Dave--may I ask
>> a naive question?
>>
>> The proposal as shown is extensive. Would it be within reach/easier to
>> pitch/feasible to implement a narrower set of changes to facilitate
>> naming convention only? Namely: alter Swift syntax to allow function
>> names to begin with "=" and adopt naming conventions that
>> mutating/non-mutating pairs of functions are named
>> =frobnicate()/frobnicate()? That would, it seems, go a long way.
>
> That would not be a small change. The strict separation between operator characters and non-operator characters is deeply embedded into Swift's grammar and compiler.
>
>
> --
> Greg Parker     gparker at apple.com     Runtime Wrangler