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

[T.J. Usiyan]

The benefit, as I see it, to this approach is not that it reduces noise. It
is that it standardizes the naming decision in a broadly applicable manner.
Look at the discussion that took place around `union` and `formUnion` to
see that this standardization could be beneficial. The argument that this
would 'add noise' seems flawed to me, since there is at least as much
'noise' in distinguishing between `sort` and `sorted`.

All of that said, I do have a concern that whatever character we use might
be too subtle or easily confused with some other meaning. I understand that
`&` was just a suggestion but, for example, the proximity to another place
where that glyph would be valid and have a different meaning is a potential
issue.

I think that we should seriously consider this, 'noise' ideas aside. If we
could agree on a convention that didn't need to consider the specific
grammar of the methods,  we would have removed a major wrinkle in designing
Swift APIs.

TJ

On Fri, Apr 22, 2016 at 8:04 AM, Patrick Smith via swift-evolution <
swift-evolution at swift.org> wrote:

> Well, you could actually have something like this now, and use whether the
> returned result was used or not to know if was a mutating or nonmutating
> method or not.
>
> Patrick
>
>
>
>
> On Fri, Apr 22, 2016 at 4:53 AM -0700, "James Campbell via
> swift-evolution" <swift-evolution at swift.org> wrote:
>
> 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
>>>
>>
>>
> _______________________________________________
> 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/6e109f3d/attachment.html>