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

Dave Abrahams dabrahams at apple.com
Thu Feb 11 19:34:38 CST 2016


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

> 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?

I don't think it's really worth exploring much further once you
acknowledge the loss of clarity to the reader at the call site ;-)

>
>
> ```
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave



More information about the swift-evolution mailing list