[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution
Radek Pietruszewski
radexpl at gmail.com
Sat Feb 13 02:47:05 CST 2016
Would you mind elaborating why is the InPlace proposal and the like unlikely to happen? Having only looked through it briefly, it seemed like a great way to avoid tricky naming issues like this thread. (Though just a convention, I found it very useful in Ruby to have foo and foo! pairs to communicate mutability)
Apologies if this was explained before and I just missed the discussion...
Sent from my iPhone
> On 12 Feb 2016, at 18:20, 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
More information about the swift-evolution
mailing list