I think that Swift has this fairly well covered so long as your mutating methods don’t need to return anything, as the type system will handle that, while @warn_unused_result (which I think is becoming the default on methods with return types?) will cover the non-mutating cases. The only place where it gets awkward is if a mutating method needs to return something, but the name of the method should ideally be something clear in such cases.
Basically I think that as long as type-checking/unused result checking and a clear naming scheme solve the problem there should be no need for a custom syntax. Aside from that I think that is something that an Xcode feature could solve; for example if mutating methods were coloured differently from non-mutating ones. > On 21 Apr 2016, at 18:08, Daniel Steinberg via swift-evolution > <[email protected]> wrote: > > Pardon me if this has been raised before. > > I gave a short presentation at our Cleveland CocoaHeads this week on what is > coming in Swift 3. One of the attendees stayed behind to ask about the naming > guidelines for mutating vs non-mutating. He is fairly new to Swift - coming > from Ruby. I have no Ruby experience but am passing his thoughts on to this > list. > > He said that in Ruby they decorate the name with a symbol (I believe in their > case it is “!”) to distinguish between the two. Although usually I’m not a > fan of such naming conventions, we do something similar with inout parameters. > > For example, if we have > > func myFunc(param: inout String) { …} > > we call it like this (using the Swift 3 first label convention) > > myFunc(param: &aName) > > We use the & to signal that the value of aName might be changed by the call > to myFunc(). > > Similarly, instead of settling on a naming convention for verb vs > verbed/verbing we could name the methods descriptively and require a symbol > (here I use & but only for illustration) to distinguish between mutating and > non-mutating > > so we would have > > myArray.sort&() > > and > > sortedArray = myArray.sort() > > Xcode and other tools could enforce this naming pattern and warn us that a > mutating method must end in “&” and that a non-mutating method is not allowed > to. > > Best, > > Daniel > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
