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

[Andrew Bennett]

+1 to '&.' or a new member accessor for mutating types. We've spent this
long arguing semantics about ing/ed just for "union", we're not going to
find a generalised and concise solution using an English suffix.

I don't think the static method is necessary, just make mutating methods
require '&.'.

Set.union would already have the type:
    (inout Set) -> Set -> Set
I think this is good.

+1 to adding mutating to reference types, thus allowing '&.' on them. I've
often thought it would be nice to have mutation checks on reference types.
Purely for better assurances about what my code can do.

On Saturday, 13 February 2016, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> On Feb 11, 2016, at 11:26 PM, Greg Parker via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/20160213/d003f490/attachment.html>