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

[David Owens II]

I don't see why not. 

Another way to potentially model it is like this:

    protocol UnionType {
      func union(other: Self) -> Self
      mutating func union(other: Self) -> Self
    }

Internally, each of these is basically this:

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

The above is suggesting that member functions have an implicit self parameter as the first parameter.

For value-types, it may even be possible to generate the mutating version.

 To call them:

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

-David

> On Feb 15, 2016, at 11:11 AM, Greg Parker <gparker at apple.com> wrote:
> 
> 
>> On Feb 12, 2016, at 9:18 PM, David Owens II <david at owensd.io <mailto:david at owensd.io>> 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.
> 
> Can you write both a mutating implementation and a non-mutating implementation of the same function with this scheme? Being able to provide both is important for performance.
> 
> 
> -- 
> Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/bf9fddeb/attachment.html>