Feedback on upcoming language changes

1

For some reason the Kotlin blog tends to eat my comments (maybe some spam filter) so I'm posting them here instead.

Re: infix functions. I appreciate and agree with the general direction. However the current behaviour is convenient for Java classes that have been deliberately augmented to support Kotlin operator overloading. I maintain a library (bitcoinj) which just did this: the Coin value class is a bit like a BigInteger, and now has methods to let Kotlin users write natural looking code. It’s a lot of additional overhead and annoyance to create a separate Kotlin library just to contain a handful of extension functions that do nothing beyond adding the “infix” modifier. Perhaps the requirement for this modifier could be relaxed for Java classes, or an annotation that can be applied in Java made available.

Re: backing fields. The rationale here does not seem very strong to me. Yes, it may be a little unintuitive how to include the backing field in a string template, but simply using concatenation can fix that, or switching to e.g. %field instead of $field. Making an identifier change its meaning inside its own definition has the potential to be confusing (it looks like it should trigger a stack overflow), and requiring a separate bit of boilerplate for the case where a class wishes to bypass the getter/setter code for its own use is ugly/verbose.

2

> Perhaps the requirement for this modifier could be relaxed for Java classes, or an annotation that can be applied in Java made available.

Thanks for bringing this use case up. We’ll probably have the annotation

> Making an identifier change its meaning inside its own definition has the potential to be confusing (it looks like it should trigger a stack overflow)

This is not what’s happening:

var foo: Bar = ...
    get
    set(v) {
        onChange(field, v)
        field = v
    }    

"foo" doesn't change its meaning. We're only adding an implicitly defined "field" variable. It's always "field", no matter what is the name of the property. Or did you mean the case when the property itself is named "field"?

> and requiring a separate bit of boilerplate for the case where a class wishes to bypass the getter/setter code for its own use is ugly/verbose.

From the use cases we’ve seen, such cases are very rare, and property delegates will address them well sometime after 1.0

3

I see, thanks. I hadn't realised the name "field" was now special.