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

[James Campbell]

What if we had a concept similar to errors and try ?

Given this function:

func sort() -> Self {
}

mutating sort() -> Self {
}


If a developer calls:

array.sort()

It will sort a copy of that array, in order to sort in place the developer
must confirm the mutation like so:

mutate array.sort()

This will then call the mutating version of sort :)

*___________________________________*

*James⎥Chief Of Fun*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 22 April 2016 at 12:31, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> This is why I mentioned Xcode; while we can have ampersand as a language
> feature for marking such things explicitly (i.e- developer consents to
> doing it), we could also just have Xcode highlight inout parameters and
> mutating methods differently, but would these represent the same explicit
> “I know that what I’m doing here will have side-effects” impact (especially
> if other IDEs add Swift support but don’t do this).
>
> > On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > From one point of view, it will be really awesome if we'll have some
> kind of 'marker' for mutating methods so we can clearly see in code if that
> method changes the instance(just like we all agree that we must specify &
> for inout parameter).
> >
> > From other point of view, this will add a much more noise(and typing) in
> code as we often(in most cases?) use mutating methods. Have a code with a
> huge number of & symbols(or other) in it - not the best thing.
> >
> > I don't see how we can unite both points.
> >
> > On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:
> >> If I recall correctly there was a thread with a similar idea which
> instead
> >> would create a new operator for mutation or a new way of method
> invocation,
> >> such that mutating methods would be called with &. or something
> similar. e.g.
> >>
> >> foo&.add(5)
> >>
> >> I think the consensus was that that was not a particularly familiar
> syntax
> >> and it would add a decent amount of noise.
> >>
> >> There may have also been some issues with the grammar, I can't recall.
> >>
> >> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
> >> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >>> Hey
> >>>
> >>> I think adding “&” to methods will reduce the readability of the code.
> >>> Also, keyword “mutating” makes it super clear and readable that my
> method
> >>> is mutating the values.
> >>>
> >>> 1. mutating func add(value: Double){…}
> >>>
> >>> 2. func add&(value: Double){…}
> >>>
> >>> I think it’s easy to skip the information encoded into the 2nd function
> >>> which is this function is mutating a value as compared to 1st. When I
> >>> read 1st function I start reading with keyword “mutating” making its
> >>> intentions clear to me.
> >>>
> >>> Also, it might become a symbol nightmare with following type signature
> of
> >>> a function-
> >>>
> >>> func nightmare&(title: String?) -> String? -> String?{…}
> >>>
> >>> I can see the advantage of using “&” when calling a function. It makes
> >>> clear at the call site that this method is mutating but still I don’t
> >>> find eliminating “mutating” a good step for the reasons mentioned
> above.
> >>>
> >>> Maybe we can think of some better solution.
> >>>
> >>> Thanks
> >>>
> >>> -Krishna
> >>>
> >>>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution
> >>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>>>
> >>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160422/54c8022e/attachment.html>