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

[Dave Abrahams]

on Fri Feb 12 2016, Taras Zakharko <swift-evolution at swift.org> wrote:

> IMO, using the converb/gerund/participle (whatever you call it) here
> is a terrible idea (I say that as someone with a PhD in linguistics :)
> ). It appears very counter-intuitive to me that ‘union’ should be the
> in-place version, as it goes agains any convention I am aware of.  I’d
> rather just keep InPlace here or, as Greg suggests, rely on compiler
> optimisations.

FWIW, I think it's almost impossible for compler optimizations to help
with arbitrarily complex LHS expressions such as a[b].c.d[e] =
a[b].c.d[e].union(f)

...and then you have the readability problem of repeated code.

>
> — Taras
>
>> On 12 Feb 2016, at 08:43, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I could get behind that. At the call site there would be little
>> visible difference between this and the alternative where functions
>> beginning with "=" are allowed. One I can think of would be that the
>> `.=` operator would require some instances (of classes that have
>> properties that are reference types) declared with `let` to be
>> declared with `var`.
>> 
>> 
>> On Fri, Feb 12, 2016 at 1:26 AM, Greg Parker via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> 
>>>> On Feb 11, 2016, at 10:05 PM, Dave Abrahams via swift-evolution
>>>> <swift-evolution at swift.org> wrote:
>>>> 
>>>>> on Thu Feb 11 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> Understandable. FWIW, if one believes in autocomplete, superscript
>>>>> equal sign is already a valid identifier head character (per
>>>>> documentation and experimentation in a playground). So, if the gist of
>>>>> the proposal is acceptable, one can already name a pair of functions
>>>>> union() and union=() if the "=" is replaced with its superscript (and
>>>>> for that matter, =union(), but autocomplete might not help with that
>>>>> one).
>>>> 
>>>> Hmm, use the fullwidth equal sign; it reads better, and compiles:
>>>> 
>>>> mutating func ＝union(other: Self) { ... }
>>>> 
>>>> Heh, that is awesome; we could do some real fun proofs-of-concept for
>>>> the proposal using that trick.  The autocomplete problem can/should be
>>>> fixed by tooling.
>>> 
>>> Now y'all are approaching the syntax of a proposal I made long ago
>>> for a .= operator. Here's what I wrote then (with a handful of
>>> syntax updates).
>>> 
>>> "
>>> 
>>> I suggest eliminating "…InPlace" as follows:
>>> 1. Use the same method name for value-creating methods and in-place
>>> mutation methods. No "…InPlace" suffix.
>>> 2. Write all client code syntactically as if the in-place
>>> implementations did not exist. Rely on the compiler to choose the
>>> in-place implementation when possible.
>>> 3. Add a new operator .= for in-place modification, to shorten the
>>> "expr = expr.method()" case.
>>> 
>>> 
>>> 1. Use the same method name for value-creating methods and in-place mutation methods
>>> 
>>> struct String {
>>>   func upper() -> String { ... }  // value-creating / out-of-place implementation
>>>   @inplace func upper() { ... }   // in-place implementation
>>> }
>>> 
>>> struct String2 {
>>>   @inplace func upper() { ... }   // in-place implementation
>>> }
>>> 
>>> The value-creating implementation is optional. If it is not
>>> present, the compiler will generate a default value-creating
>>> implementation that copies the object and calls the in-place
>>> implementation. There is no default in-place implementation; if
>>> there is no in-place implementation of a value-creating method then
>>> the compiler simply fails to optimize to it.
>>> 
>>> 
>>> 2. Write all client code syntactically as if the in-place implementations did not exist.
>>> 
>>> Instead of this
>>>   s.upperInPlace()
>>> write this
>>>   s = s.upper()
>>> 
>>> The compiler optimizer can choose the in-place upper() implementation if it is present.
>>> 
>>> Instead of this
>>>   t = s.upper().trim().truncate(toLength: 5) // oops, there's an
>>> extra copy here
>>>   t = s.upper().trimInPlace().truncateInPlace(toLength: 5)  // oops, compile error
>>> write this
>>>   t = s.upper().trim().truncate(toLength: 5)
>>> 
>>> The developer can chain methods together and let the compiler
>>> optimizer choose which in-place implementations to use. In this
>>> case, if all in-place implementations are available, it should call
>>> value-creating upper() followed by in-place trim() and in-place
>>> truncate(toLength:).
>>> 
>>> 
>>> 3. Add operator .= for in-place modification.
>>> 
>>> Operator .= is analogous to arithmetic operators like += . It is
>>> shorthand for `expr = expr.stuff` for the case where `expr` is
>>> inconveniently long. (It also doesn't evaluate `expr` twice, if
>>> Swift's optimization rules otherwise would allow it or require it
>>> for the longhand case.)
>>> 
>>> s .= upper()
>>> // like s = s.upper()
>>> 
>>> p .= next
>>> // like p = p.next
>>> 
>>> some().long().expression .= upper().trim().truncateToLength(5)
>>> // like some().long().expression =
>>> some().long().expression.upper().trim().truncateToLength(5)
>>> 
>>> As seen in this last example, one advantage of this syntax is that
>>> it allows chained mutations but cleanly separates the "lookup"
>>> calls from the "mutate" calls. This is an improvement upon language
>>> and API designs with mutating methods where the property being
>>> changed is buried in the middle of the expression somewhere.
>>> 
>>> some().long().expression.upperInPlace().trimInPlace().truncateInPlace(toLength: 5)
>>> some().long().expression().upper.trimInPlace().truncateInPlace(toLength: 5)
>>> 
>>> some().long().expression .= upper().trim().truncate(toLength: 5)
>>> some().long().expression().upper .= trim().truncate(toLength: 5)
>>> 
>>> 
>>> One consequence of these changes is that compiler optimizations to
>>> take advantage of in-place implementation are much more important
>>> for performance, because there isn't any syntax to call the
>>> in-place implementation directly.
>>> 
>>> "
>>> 
>>> 
>>> --
>>> Greg Parker     gparker at apple.com     Runtime Wrangler
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave