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

[Evan Maloney]

With a little tweak to Swift's type inference with respect to return values, you could provide two parallel signatures for in-place/not-in-place variants.

Imagine a FakeSortable that provided two sort() functions, one in-place and one not:

struct FakeSortable
{
    private var sortMe: [Int]

    init() { sortMe = [3, 5, 4, 2, 1] }
    init(_ sort: FakeSortable) { sortMe = sort.sortMe }

    mutating func sort()
    {
        print("sorting in place")
        
        sortMe = [1, 2, 3, 4, 5]
    }
    
    func sort() -> FakeSortable
    {
        print("returning new FakeSortable")

        var sort = FakeSortable(self)
        sort.sort() as Void
        return sort
    }
}

The thing that makes it unwieldy is that Swift can't infer the return type correctly without explicit help.

As a result, you have to call the in-place sort like this:

var toSort = FakeSortable()
toSort.sort() as Void

...and you have to call the sort-that-returns-a-new-instance as:

var another: FakeSortable = toSort.sort()

or as:

var another = toSort.sort() as FakeSortable

It seems to be Swift should be able to disambiguate purely based on the return, given that:

1. There are only two return types
2. One of them is a Void type
3. The other return supplies a value

Therefore, if one call assigns the return value and the other does not, Swift should figure out what to call unambiguously.

If I call "toSort.sort()" with no l-value to assign the return to, Swift should figure out that I'm calling the variant that returns Void.

Conversely, if I call sort() and assign the result to something, Swift should assume I'm _not_ calling the Void variant.

If Swift were able to do this, it might be feasible to use the same name for the in-place and not-in-place variants of things like sort() and not have things look ugly at the call-site.

Whether or not that is a good idea, is another discussion :)

Evan



> On Feb 12, 2016, at 12:20 PM, 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