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 < [email protected]> 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" <[email protected]> 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* >> >> *[email protected] <[email protected]>⎥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 < >> [email protected]> 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 < >>> [email protected]> 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 >>> >> <[email protected] <mailto:[email protected]>> 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 >>> >>>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>>> >>> >>>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> _______________________________________________ >>> >>> swift-evolution mailing list >>> >>> [email protected] <mailto:[email protected]> >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
