<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I kinda get where your coming from, but this really seems like a calling convention problem. You can have two functions that are nearly identical with the *only* difference being the modification of `self` versus returning a copy.<div class=""><br class=""></div><div class="">If we are really going to try and use a name, the suffix `InPlace` is atleast *always* consistent and never ambiguous, unlike nearly every attempt at using different pairs of noun and verb forms.</div><div class=""><br class=""></div><div class="">If we are willing to treat the calling syntax differently, then I think we can at least come up with a non-ambigous form. I think it even applies more generally throughout the language.</div><div class=""><br class=""></div><div class="">The two function signatures are this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> func union(other: Self) -> Self<br class=""> mutating func union(other: Self) -> Self</font></div><div class=""><div class=""><br class=""></div><div class="">However, the mutating version is now just syntactical short-hand for this:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> static func union(inout this: Self, _ other: Self) -> Self</font></div><div class=""><br class=""></div><div class="">This changes the language to **not** allow a mutating function to be called with the “.” operator; after all, it’s really a static member now.</div><div class=""><br class=""></div><div class="">At the call site, you’d have the following:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> var a: Set<Int> = [1, 2]</font></div><div class=""><font face="Menlo" class=""> let b: Set<Int> = [3, 4</font><span style="font-family: Menlo;" class="">]</span></div><div class=""><span style="font-family: Menlo;" class=""><br class=""></span></div><div class=""><span style="font-family: Menlo;" class=""> a.union(b) // this is *always* the non-mutating one</span></div><div class=""><span style="font-family: Menlo;" class=""> </span></div><div class=""><span style="font-family: Menlo;" class=""> Set.union(&a, b) // normal syntax for static methods, mutates `a`</span></div><div class=""><span style="font-family: Menlo;" class=""> a&.union(b) // streamlined calling syntax, mutates `a`</span></div><div class=""><span style="font-family: Menlo;" class=""><br class=""></span></div><div class=""><font face="Menlo" class=""> b&.union(a) // error: Cannot using mutating member on immutable value ‘b’.</font></div><div class=""><br class=""></div><div class="">This model works with class types as well, but suffers from all of the same limitations today with regards to the ability to enforce member mutation.</div><div class=""><br class=""></div><div class="">This brings two language changes:</div><div class=""><br class=""></div><div class="">1. Any function can be declared with the mutating modifier. This is syntactic sugar for a static function with the first parameter being an `inout` of Self. This works for both value and reference types.</div><div class="">2. Any static function that has an unlabeled `inout` parameter of `Self` can be invoked with a short-hand syntax of `&.` instead of the full static calling form.</div><div class=""><br class=""></div><div class="">Maybe there are some other limitations with this approach that I’m not thinking of at the moment.</div><div class=""><br class=""></div></div><div class="">-David</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 12, 2016, at 9:20 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Feb 11, 2016, at 11:26 PM, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">3. Add a new operator .= for in-place modification, to shorten the "expr = expr.method()" case.<br class=""></blockquote><br class="">.= doesn’t really make sense in the context of Swift. Proposal’s like the (obsolete and unlikely to happen) inplace proposal work by making the = part of the name. This is important because methods (including the in place assignment operations) should be curryable. <br class=""><br class="">IOW, the Equal is part of the name of the method, it isn’t part of the “operation of calling the method”.<br class=""><br class="">That said, as Dave mentioned before, we discussed this extensively in the Swift 2 timeframe because it introduces yet-another concept very similar but different to the existing “mutating” keyword, and doesn’t have obvious semantics for classes. After trying very hard to make something like it work, we agreed that it was better to put the complexity of this back into the space of naming, rather than adding confusing new language features.<br class=""><br class="">-Chris<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>