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

Tyler Cloutier cloutiertyler at aol.com
Fri Apr 22 02:00:08 CDT 2016


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> 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> wrote:
>> 
>> swift-evolution at swift.org
> 
> _______________________________________________
> 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/34e0df80/attachment.html>


More information about the swift-evolution mailing list