Kotlin statics and static extensions

[elizarov]

This is an issue for discussion of Kotlin statics and static extensions proposal. This proposal is the culmination of our research and design on KT-11968 Research and prototype namespace-based solution for statics and static extensions.

The full text of the proposal is here.

Please, use this issue for the discussion on the substance of the proposal. For minor corrections to the text, please open comment directly in the PR #347.

OPEN ISSUE: This proposal has a major open issue on what kind of declaration syntax to use for static members: static sections or static modifiers. See Static section vs static modifier for details on their pros and cons. The text of the proposal is written showing both alternatives side by side.

Let's use this issue for an ad-hoc voting on the syntax via reactions:

• Use 🎉 reaction to vote for static sections syntax.
• Use 🚀 reaction to vote for static modifiers syntax.

Please, read the proposal before voting!. If you are just excited about the future introduction of statics in Kotiln, then react with 👍. If you don't like the idea at all, then react with 👎 and explain your concerns in the comments.

[JakeWharton]

Great write-up, but there doesn't seem to be any information about the ABI of platforms other than the JVM. What's the ABI of JS, and is it blocked/require ES2015 output from the compiler? Does the Objective-C interop use class methods or something else?

Also curious if external static function declarations work on JVM and JS?

[SPC-code]

(on behalf of @altavir)
Looks nice. I definitely like blocks more than modifier. It follows the overall tendency of using scopes to designate changes of code block semantics. It also encourages to group static statements together instead of placing them in random places in the class.

Also it would be nice to consider using namespace used in early design instead of static. I understand that static is familiar from other languages. But namespace better corresponds to the role the feature plays in Kotlin. In Java, where everything is a class and must be dynamically instantialized, it makes sense. But in Kotlin we have top level functions, objects etc. The concept of static does not make a lot of sense. On the other hand namespace makes a lot of sense. It emphasizes the fact that we have a concept of a named scopes (packages, objects, classes, etc) and we can create namespace hierarchies.

The question of interoperability with JS is also interesting in the context of https://youtrack.jetbrains.com/issue/KT-46164

[axelfontaine]

The concept of "static sections" could be generalized to "modifier sections" with equivalent private and internal sections. Each modifier section would then apply its modifier implicitly to all contained members.

In cases where it would favor readability, these sections could be collapsed to regular modifiers as used presently.

While the proposal explicitly rejects such a hybrid approach for static, the more general case may be worth considering nonetheless.

[mikehearn]

Great proposal. Only one observation for the JVM mangling scheme - $ is not that readable, but the other proposals might be confusing e.g. I wouldn't immediately think that getBackgroundColor would map to Color.static.background if I saw it in a stack trace.

Other alternatives:

• Color_background
• Color::background (: is an allowed character in JVM unqualified names)
• static extension Color getBackground (spaces are allowed in JVM unqualified names)

[Maxr1998]

Thanks for the proposal, this looks very promising. Personally, I lean towards static sections, the only thing I don't appreciate is the verbosity of a single static constant property declaration. I understand that supporting both static sections and static modifiers generally is not an option, but what if this would be dependent on the declaration type?

E.g., static sections could be required for functions, extensions and getters, whereas only static constant properties could support the static modifier syntax (exclusively, or in addition to static sections). This would solve the verbosity issue and only slightly increase complexity. The code style discussion remains, but for constants only it isn't as impactful, from my perspective.

[streetsofboston]

Great proposal!

Few concerns that popup in my head.

Will companion objects be deprecated? I hope not, since these can implement an interface. Or will static interfaces allow for a similar way of having a static 'reference' (in code that uses it) that satisfies that interface?

I'm not a fan of static objects being effectively a namespace (no this reference). The word object implies there is a this reference (to that object). I would favor a new keyword, eg namespace.

[mikehearn]

Another suggestion - the distinction between object and static object is unfortunate. Complexity that will exist forever. Is it maybe not possible to just automatically change how it's compiled depending on whether the object actually contains any state. To avoid binary compatibility breaks on the JVM, the instance and forwarding methods can just always be generated unless you explicitly opt out. That would avoid the need to explain the difference which could be difficult, especially to people learning programming for the first time.

[mcpiroman]

Alternative proposals:

1. instead of static section have static companion object, so that it is symmetric with static object, or
2. (IMHO better) as mentioned above, replace static object with namespace, thus also having companion namespace (instead of static section).

Pros of 1):

• Symmetry: you can mark both objects and companion objects static, both having the same semantics (and also the same as in KEEP).
• Symmetry in extensions: both static and regular companion objects can be extended with the same syntax (fun MyClass.Companion.foo(). KT-11968 is solved by all classes implicitly having an empty static companion object. It can be then explicitly replaced with user-specified one, either static or not.
• Less new concepts in language (static keyword only on objects, no new static blocks).

Cons of 1):

• You (probably) cannot have both static and not-static object in a class.
• You (probably) cannot have multiple static companion objects like you can with static sections.
• static companion object is rather lengthy.
• static companion object looks kind of like static classes in Java - confusing and boilerplatey

But those cons are solved in option 2):

• There can be both companion object and companion namespace in a class.
• You (probably) can have multiple multiple companion namespaces in a class
• The symmetry is still achieved with namespace and companion namespace
• You can have both named and companion namespace in a class, the same as you can now have both named and companion objects.
• Like in 1), KT-11968 is solved by all classes implicitly having an empty companion namespace which can be extended.
• Extensions are (probably) like in the KEEP - fun MyClass.namespace.foo(). namespace in this context also looks slightly more meaningful than static,

[sandwwraith]

I agree with the suggestion to replace static object with namespace. IMO a lot of people read 'singleton' when they see object, and 'static singleton' doesn't make a lot of sense. As you said yourself:

Static modifier is not allowed on other declarations (including class, interface, and typealias declarations). Rationale: static modifier on a class, interface declarations make no sense, as such declarations are already static by default and do not have access to an outer class instance.

The exact same rationale is also applicable to objects.

[SPC-code]

I also like MyClass.namespace.something() much better than MyClass.static.something().

[sandwwraith]

I even would go further and suggest allowing namespace modifier on ext functions, to replace fun Color.static.myExtension() with namespace fun Color.myExtension(). IMO, the latter nicely reads as 'function in the namespace of Color'. Color.static, on the other hand, introduces some specific entity that is a special case — normally, we are allowed to write fun A.B.x() only if B is a class or object inside A. Avoiding special cases and providing concise, but explicit syntax is one of the Kotlin's design cornerstones.

[sandwwraith]

I see there's suggestion for further improvements to use with(Color.static) {} to use static functions without prefix: https://github.com/Kotlin/KEEP/blob/statics/proposals/statics.md#static-scope-projection-reference

Does it mean that regular with(Color) {} will allow only using companion object functions without prefixes, but still would require Color. to call static ones?

[mcpiroman]

@streetsofboston

Will companion objects be deprecated?

It is a non-goal of this proposal to deprecate or to completely replace companion objects.

[TheBestPessimist]

Can someone explain me please the following: in the example Option: Static section syntax, copied below:

class Outer(val one: String, val two: String) {
    static {
        fun createMappings(): List<String> =
            setOf(::one, ::two).map { it.name } // WORKS! No need to write Outer::one, Outer::two
    }
}

because createMappings is a static, this means i don't need an instance of Outer to call the static function.
So i can just do

val l: List<String> = Outer::createMappings()

My problem with this is that one and two and it.name are instance variables of Outer, which means that they do not exist in my example above.

The example looks wrong to me, but I assume it's not wrong and I'm just misunderstanding something.

[spen37]

Overall I love this proposal but I echo the sentiments of using namespace over static object as there is no "object" to speak of.

Also seems to be an unpopular opinion but I favour the modifier syntax over the sections. This is just my personal opinion but I feel the verbosity of a whole separate section makes this feel like a shorthand for just declaring a companion object. On that note, I understand the syntax for static extensions makes a ton of sense when you use sections, but from the modifiers perspective would something like static fun SomeClass.someMethod() make more sense?