[swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Xiaodi Wu]

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution <
swift-evolution at 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 at 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.
>

Yes, I suggested this a while back, and it was rejected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/f6b3e5ad/attachment.html>