Typed delegate access

[e2e4b6b7]

This is an issue to discuss typed delegate access. The current full text of the proposal can be found here.

This proposal describes a way to access a typed value of a delegate within the private scope:

class C {
  val dbConnection by lazy { connectToDb() }

  fun close() {
    // Access to the backing property delegate of type Lazy<DbConnection>  
    if (::dbConnection.isInitialized()) { 
      dbConnection.close()
    }
  }
}

[IRus]

This proposal describes a way to access a typed value of a delegate within the private scope:

Is it possible to lift this restriction and explicitly allow access in public scope as well?

For example, I have DI library which suffers from .value boilerplate just because I need to access delegate to call .mock

[e2e4b6b7]

Current proposal does not include such an option.

It might be possible in theory, but this option is quite expensive because it requires new syntax. Thus, we need a strong evidence of high demand for it.

[JakeWharton]

Pretty strongly opposed to such a thing. At the very least it would require a separate visibility modifier for the delegate, such as by public lazy { }, otherwise you violate encapsulation rules of existing code on recompilation.

Having behavior that matches explicit backing fields (since this language feature is "just" a convenience for a backing field that holds the delegate instance anyway) seems logical.

[kyay10]

How does this work with local delegated properties? My understanding is that property references to them aren't allowed, but they're also effectively "private", so it'd be nice (especially for DSLs) to be able to access the delegate in this way.

There are many example use cases here. Obviously, lazy is a clear one since someone locally using by lazy might still want access to isInitialized

[e2e4b6b7]

This KEEP does not address support of references to variables. This remains an open issue: KT-16303

[Martmists-GH]

I'm not sure I'm sold on using :: as prefix for accessing delegates, what was the rationale for this over something like attr::delegate? This would closely match attr::set and attr::get as well, and could eliminate the need to use .getDelegate()

[e2e4b6b7]

An issue with attr::delegate is that it already has an existing meaning, making it backwards-incompatible. Additionally, this syntax does not work for extension delegates:

val Int.prop by smth()

// would this be `Int::prop::delegate`?

With any other proposed syntax, the main issue is that it introduces new language syntax. In contrast, the approach described in the KEEP does not add anything new. It only provides better typing and enables optimizations around existing functionality.

[Martmists-GH]

// would this be Int::prop::delegate?

Yes, as this would match Int::prop::get (and Int::prop::set for mutable fields/extensions)

[rnett]

This looks great, I have definitely wanted something like this a number of times.

My biggest concern is the different runtime behavior between JVM and other platforms shown in the "Behavior in different scopes" section. This is an easy to run into footgun. I'm guessing it occurs because the delegate field is private?

IMO, the behavior should be consistent across all platforms, even if it limits the functionality. I would think this either means that bridges need to be generated for delegates (don't know how much overhead that adds) or that getDelegate needs to throw for private properties on all platforms.

[e2e4b6b7]

These cases are not an intended way to use this feature. In fact, they are not part of the feature, but just a pure reflection. Similar differences in reflection already exist in other comparable scenarios. Reflection always requires caution, so this should not be a significant issue.