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

Sat Feb 13 11:13:46 CST 2016

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

>> On 12 Feb 2016, at 17:29, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Fri Feb 12 2016, Taras Zakharko
>
>> <swift-evolution at swift.org
>> <mailto: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.
>
> I don’t think that the problem is that complicated: if the compiler
> detects that the invoked member has a in-place version, it just needs
> to check that the expression ASTs on the left and right side are
> identical (and that no getters have side effects). 

The devil is in the parentheses, brother.

> In the end, its just a special case of CSE, but its also true that
> Swift does not seem to do anything like this right now.
>
>> 
>>> 
>>> — 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
>>> <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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