[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution

[David Owens II]

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.

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.

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.

The two function signatures are this:

    func union(other: Self) -> Self
    mutating func union(other: Self) -> Self

However, the mutating version is now just syntactical short-hand for this:

    static func union(inout this: Self, _ other: Self) -> Self

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.

At the call site, you’d have the following:

    var a: Set<Int> = [1, 2]
    let b: Set<Int> = [3, 4]

    a.union(b)        // this is *always* the non-mutating one
    
    Set.union(&a, b)  // normal syntax for static methods, mutates `a`
    a&.union(b)       // streamlined calling syntax, mutates `a`

    b&.union(a)       // error: Cannot using mutating member on immutable value ‘b’.

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.

This brings two language changes:

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.
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.

Maybe there are some other limitations with this approach that I’m not thinking of at the moment.

-David

> On Feb 12, 2016, at 9:20 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Feb 11, 2016, at 11:26 PM, Greg Parker via swift-evolution <swift-evolution at swift.org> wrote:
>> 3. Add a new operator .= for in-place modification, to shorten the "expr = expr.method()" case.
> 
> .= 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.  
> 
> IOW, the Equal is part of the name of the method, it isn’t part of the “operation of calling the method”.
> 
> 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.
> 
> -Chris
> _______________________________________________
> 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/20160212/5515970c/attachment.html>