mutating/non-mutating suggestion from a Rubyist

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.

From James F

Yes +1 I think how the compiler can’t work with two methods with the same name, where one has a result, and other mutating, needs to be fixed to enable nice APIs.

Patrick

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.

···

On Sun, Apr 24, 2016 at 2:33 AM -0700, "James Froggatt via swift-evolution" <swift-evolution@swift.org> wrote:

From James F

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.

> From James F

Can’t we do this for every mutating method? i.e.

var numbers = [1,3,2]
let sorted = numbers.sort()
// sorted is [1,2,3], numbers is [1,3,2]
numbers.sort()
// numbers is [1,2,3]

I suppose this would require that the mutating version doesn’t return anything, and I don’t know if that’s ever a problem.

The idea of distinguishing all mutating/non-mutating functions with only the assignment operator did occur to me as I wrote that.
Using such a rule would allow automatic generation of mutating methods from non-mutating ones, since the naming would no longer need changing.
However, this would also mean scrapping half the Naming Guidelines, so I'm hesitant to put that possibility forward as a serious proposal.

I think union (verb) vs union (noun) would work as a one off, though, since it fits the guidelines as they currently stand. It would be a nice way to demonstrate that the compiler can make the distinction in a public API.

From James F

···

On 24 Apr 2016, at 15:49, Tim Vermeulen <tvermeulen@me.com> wrote:

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.

Have we considered this, then:

a.union(b) //mutating

_ = a.union(b) //non-mutating

There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.

Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.

From James F

Can’t we do this for every mutating method? i.e.

var numbers = [1,3,2]
let sorted = numbers.sort()
// sorted is [1,2,3], numbers is [1,3,2]
numbers.sort()
// numbers is [1,2,3]

I suppose this would require that the mutating version doesn’t return anything, and I don’t know if that’s ever a problem.

Well, right now(Swift 2) we can have such code (yes, it will raise warnings, but will compile and run without errors. i.e. this is a valid code):

var a = [1,2,3]
let a1 = a.sortInPlace(>) // a1 == ()
let a2 = a.sort(>) // a2 == [3,2,1]

Note, how sortInPlace is explicit. Now, change to sort/sorted:

var a = [1,2,3]
let a1 = a.sorted(>) // IMO not explicit about the result
let a2 = a.sort(>)

For your proposal we need to disallow assignment of Void to variable, otherwise compiller can't choose which one to use. Or, in case of your proposal, documentation should explicitly say(and compiler implemented in this way) that non-mutating function should be selected if result is used.

···

On 24.04.2016 17:49, Tim Vermeulen via swift-evolution wrote:

Can’t we do this for every mutating method? i.e.

var numbers = [1,3,2]
let sorted = numbers.sort()
// sorted is [1,2,3], numbers is [1,3,2]
numbers.sort()
// numbers is [1,2,3]

I suppose this would require that the mutating version doesn’t return anything, and I don’t know if that’s ever a problem.

The idea of distinguishing all mutating/non-mutating functions with only the assignment operator did occur to me as I wrote that.
Using such a rule would allow automatic generation of mutating methods from non-mutating ones, since the naming would no longer need changing.
However, this would also mean scrapping half the Naming Guidelines, so I'm hesitant to put that possibility forward as a serious proposal.

I think union (verb) vs union (noun) would work as a one off, though, since it fits the guidelines as they currently stand. It would be a nice way to demonstrate that the compiler can make the distinction in a public API.

> From James F

> > The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.
> >
> > Have we considered this, then:
> >
> > a.union(b) //mutating
> >
> > _ = a.union(b) //non-mutating
> >
> > There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.
> >
> > Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.
> >
> > > From James F
>
> Can’t we do this for every mutating method? i.e.
>
> var numbers = [1,3,2]
> let sorted = numbers.sort()
> // sorted is [1,2,3], numbers is [1,3,2]
> numbers.sort()
> // numbers is [1,2,3]
>
> I suppose this would require that the mutating version doesn’t return anything, and I don’t know if that’s ever a problem.

Well, this change would render a big part of the naming guidelines meaningless, but isn’t that a good thing? Guidelines are often in place to prevent ambiguity, and this solution would do that without the need for guidelines.

Anyways, I wouldn’t be surprised if this idea has come up before and has been rejected, but to me it sounds like a good idea.

···

On 24 Apr 2016, at 15:49, Tim Vermeulen<tvermeulen@me.com>wrote:

Yes, I suggested this a while back, and it was rejected.

···

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote:

> The idea of distinguishing all mutating/non-mutating functions with only
the assignment operator did occur to me as I wrote that.
> Using such a rule would allow automatic generation of mutating methods
from non-mutating ones, since the naming would no longer need changing.
> However, this would also mean scrapping half the Naming Guidelines, so
I'm hesitant to put that possibility forward as a serious proposal.
>
> I think union (verb) vs union (noun) would work as a one off, though,
since it fits the guidelines as they currently stand. It would be a nice
way to demonstrate that the compiler can make the distinction in a public
API.
>
> > From James F
> On 24 Apr 2016, at 15:49, Tim Vermeulen<tvermeulen@me.com>wrote:
>
> > > The whole naming issue seems to be caused by the .union(_:)
function. The Swift Guidelines say that mutating functions should use a
verb, and non-mutating forms should use a noun, but in this case, the word
union itself is a verb and a noun.
> > >
> > > Have we considered this, then:
> > >
> > > a.union(b) //mutating
> > >
> > > _ = a.union(b) //non-mutating
> > >
> > > There is no ambiguity in most situations, and the fact the Swift
compiler can't disambiguate this at the moment is a bug I'd like to see
fixed in the Swift 3 timeframe. I think this wouldn't be such a bad
compromise, and other functions could still use the standard -ed/-ing
system alongside this without the API looking inconsistent, unlike with the
form- prefix.
> > >
> > > Admittedly, there is merit to the idea that functional methods
should make non-mutating forms the primary form, but I feel like we should
figure out what our stance is on this methodology in general. A mention in
the Guidelines one way or the other would be nice, since the current rules
seem to support this.
> > >
> > > > From James F
> >
> > Can’t we do this for every mutating method? i.e.
> >
> > var numbers = [1,3,2]
> > let sorted = numbers.sort()
> > // sorted is [1,2,3], numbers is [1,3,2]
> > numbers.sort()
> > // numbers is [1,2,3]
> >
> > I suppose this would require that the mutating version doesn’t return
anything, and I don’t know if that’s ever a problem.
>
>
>

Well, this change would render a big part of the naming guidelines
meaningless, but isn’t that a good thing? Guidelines are often in place to
prevent ambiguity, and this solution would do that without the need for
guidelines.

Anyways, I wouldn’t be surprised if this idea has come up before and has
been rejected, but to me it sounds like a good idea.

That makes it sound much more definitive than anything on this list
other than a formal review response can ever be. What actually
happened?

···

on Sun Apr 24 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

    Anyways, I wouldn’t be surprised if this idea has come up before and has
    been rejected, but to me it sounds like a good idea.

Yes, I suggested this a while back, and it was rejected.

--
Dave

Me:

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?

You:

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 ;-)

(I think the smiley really seals the deal in terms of definitiveness of
rejection, no?)

···

On Mon, Apr 25, 2016 at 17:05 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Sun Apr 24 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

> Anyways, I wouldn’t be surprised if this idea has come up before and
has
> been rejected, but to me it sounds like a good idea.
>
> Yes, I suggested this a while back, and it was rejected.

That makes it sound much more definitive than anything on this list
other than a formal review response can ever be. What actually
happened?

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hey, that was just my opinion at the time; that doesn't mean the
community rejected the idea or the core team rejected the idea [or even
that I still believe the same thing this week ;-)]

···

on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

Me:

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?

You:

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 ;-)

(I think the smiley really seals the deal in terms of definitiveness of
rejection, no?)

--
Dave