The `$backingField` scheme was simpler and more powerful


#1

Is there any chance of resurrecting the `$backingField` syntax (even if a character other than `$` is used)?  The new `field` scheme seems both more restrictive and more complicated to me.

For example, this confused me tonight:

class Message(text: String) {   val text: String   get() = ""      init {   this.text = text // ERROR: "Val cannot be reassigned"   } }

As far as I can tell, the problem here is that a backing field hasn't been generated.  Please correct me if I'm wrong.  (If we replace `get() = ""` with `get() = field`, it compiles fine.)

This issue wouldn’t have occurred when we could say say $text = text, which avoids the confusion entirely.

Another example of how the new scheme can be confusing:

class Message(text: String) {   var text: String   get() = ""   set(value: String) {         field = value      }      init {   this.text = text // ERROR: "This property has a custom setter, so initialization using backing field required"   } }

I think the old way would have been `$text = text`, with no confusion or error message.

I keep seeing arguments in favour of the $backingField syntax.  It seems unfortunate that it was dropped.


#2

There was a mention somewhere, that to set initial value of the backing field, you have to initialize it directly on definition

class Message(text: String) {
    var text: String = text
        get() = ""
        set(value: String) {
            field = value
        }
}

#3

It's very much intentional that the new scheme is more restrictive than the old one. We looked at how people used backing fields in existing Kotlin code, and found that most of the usages were completely unnecessary.

Can you please show any examples where you need the power of the old implementation that don’t boil down to complicated ways of writing “class Message(val text: String)”?