[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


More information about the swift-evolution mailing list