Static members and type extensions

[serras]

This is an issue to discuss static members and type extensions. The current full text of the proposal can be found here.

We propose to bring the idea of statics in Kotlin with static members and type extensions.
The underlying idea is surfacing the notion of static scope more clearly in the language.

ℹ️ This is our first attempt to use GitHub discussions for KEEP review. Please try to reply on the appropriate thread, and to create separate messages for different feedback or concerns, so we can keep everything tidy.

[tKe]

Was there any consideration of using a static { } block for defining static-scoped members rather than introducing a static modifier for members? One of the major draws for the companion-object approach is the inherent grouping of same-scoped members and the explicit movement from one scope to another in the structure.

class Direction {
  static {
    val UP: Direction
    val DOWN: Direction

    val entries: EnumEntries<Direction>
    fun valueOf(value: String): Direction
    fun values(): Array<Direction>
  }
}

[CLOVIS-AI]

Furthermore, adding a block for static leaves us with the oddity of the instance members lexically living in an outer scope with compared to static ones. I think we need to have them at the same level.

Are there reasons in particular for this want? I explicitly do not want them at the same level. Currently lifetime is declared by the brackets in which something is declared, and I think there is a lot of value in keeping this rule that simple, without exceptions—even more so because lifetime in Kotlin never appears explicitly, unlike languages like Rust which have abstractions to deal with it.

[CLOVIS-AI]

In fact, the KEEP tries to follow the current model in Kotlin. Because right now you can declare static properties in Kotlin; you just need to declare a pair of static accessors in Java! So the language (or if we are very precise, JetBrains' implementation) already has a notion of "class member scope".

Can you clarify how this can be done in Kotlin at the moment?

[serras]

Can you clarify how this can be done in Kotlin at the moment?

Sorry, my bad here, this only applies to functions at this moment. But I think the point stands: there's already a notion of "static things" coming from the interoperability layer with Java.

[serras]

I think that in the end, this is the main contradiction. There are two styles of Kotlin right now: better Java and the one frequently called idiomatic Kotlin.

Definitely, although I don't think that there are too contradictory. But it raises the question of whether the population responding to the KEEP is skewed towards one of the styles, and have made up their mind already.

Again, looking at our YouTrack you can see lots of problems when people, for example, try to use JUnit with Kotlin because some methods must be static, and writing that in Kotlin is painful. For these users the current Kotlin model just gets in the way of making their code work.

Note that in general the Kotlin team cares a lot about interoperability with other platforms (not only Java, but also JS, WebAssembly, and Swift), and we want the most common patterns from those communities to have a counterpart in Kotlin. Sometimes we can bridge it in the translation layer, but I would say that statics is so common among those platforms that having them in Kotlin is a win.

[serras]

Reiterating on this, I think that a bit schism here is whether the problems enumerated in the KEEP are problems at all! Because sometimes I perceive that the proposed features are completely orthogonal to those problems, with their link being some kind of similarity in bringing new kinds of scopes not tied to an instance.

I don't want to stop the discussion, but I want it to be more constructive. I see this potentially in two levels:

1. Giving counterarguments for the problems,
2. Raising concerns about the proposed solutions for (1).

If you disagree with (1), it's very difficult to have a constructive discussion about (2).

[stevenlele]

I think this example from §5.4 (type extensions, no mangling scheme) either requires backing fields in JVM or is missing get() notations in Kotlin.

As a result of the rules above, the following Kotlin code:

data class Vector(...) {
  static val Zero: Vector = Vector(0.0, 0.0)
}

val Vector::type.UnitX: Vector = Vector(1.0, 0.0)

would be compiled down in the JVM as follows:

class Vector {
  public static Vector getZero() { return new Vector(0.0, 0.0); }
}

class MyFileKt { // defined in myFile.kt
  public static Vector getUnitX() { return new Vector(1.0, 0.0); }
}

[serras]

You are completely correct. I've just pushed a new version with the correct implementation (I copy it below for quicker reference).

class Vector {
  private static Vector Zero = new Vector(0.0, 0.0); // backing field
  public static Vector getZero() { return zero; }
}

class MyFileKt { // defined in myFile.kt
  public static Vector getUnitX() { return new Vector(1.0, 0.0); }
}

[stevenlele]

@serras There's a typo in getZero():

public static Vector getZero() { return zero; } // should be `return Zero`

And I think UnitX needs a backing field too.

Speaking of which, there's no explicit mentioning of type extension properties allowing generating backing fields, as opposed to normal class extension properties.

Furthermore, the proposal fails to clearly cover all the possible static-applicable scenarios and compilation results - I had to read through all the examples to know the mechanism of type extension properties. Not to mention static init blocks, which are only mentioned once in §4.4 without any example. Maybe you wrote this proposal assuming readers have understood the old proposal content, which makes this new one unclear on its own. I think it's better to add more basic examples like the old version.

[serras]

Thanks for looking at the specification with a critical eye. Indeed there were a bunch of get() missing on the extension properties; the rules for when backing fields are created are not changed by this proposal; and there was a missing paragraph about static initialization blocks.

My goal is to make this proposal self-contained -- except for those parts already coming from the Kotlin specification. What do you feel are other missing parts?

[Peanuuutz]

I still feel like simply naming it namespace universally could work better, so for

class A {
    namespace fun B::namespace.foo() {}
}

we call foo "a function that lives in namespace A (think of every single type declaration having a companion namespace) and extends namespace B". These two namespaces are clearly different as their subjects are different.

::type, on the other hand, is not as accurate as this, as List<Int> is a type, where as if we extend the "thing" it's actualy just the namespace List.

This could also nicely introduce standalone namespace feature for much more cooperative grouping work.

namespace FlowCollection {
    suspend fun <T> Flow<T>.collect(): Unit

    suspend fun <T> Flow<T>.collectToList(): List<T>
}

[serras]

Following on the namespace idea; what are the use cases you foresee for something like FlowCollection? Why do you feel such a "cooperative grouping" is useful for: library authors, large APIs, application developers, ...?

[SPC-code]

Standalone namespaces are a good thing. And they were discussed it a lot in previous design discussion: #348. @serras please review it. At least the most liked comments.

I personally like companion namespace block proposal the most. Because it both leverages namespace mental model and reuses current companion object model.

[lounres]

Following on the namespace idea; what are the use cases you foresee for something like FlowCollection?

@serras I have similar use case.

For example, I have two classes, both called GameSettings. One of them is used as a serializable class for WebSocket data transmission. Another one is used for describing state of server-side state machine (and it contains an instance that provides specific access to data in DB, so it cannot be serialized). Actually, there are a lot of such classes pairs. So I would like to encapsulate them in two different namespaces. But for now I use an object for such namespaces. I.e.:

// Server API package.
package dev.lounres.halfhat.api.onlineGame

public object ServerApi {
    ...
    
    public data class GameSettings(
        ...
    )
    
    ...
}

// Package for my game's state machine.
package dev.lounres.halfhat.logic.gameStateMachine

public object GameStateMachine {
    ...
    
    public data class GameSettings<out WP: WordsProvider>(
        ...
    )
    
    ...
}

// Final server package.
// It also contains logic that converts state machine's state into serializable representation for player (client).
package dev.lounres.halfhat.server

public fun <WP: WordsProvider> GameStateMachine.GameSettings<WP>.toApi(): ServerApi.GameSettings {
    ...
}

I could use packages with names ServerApi and GameStateMachine instead, but then I would not be able to write ServerApi.GameSettings instead of dev.lounres.halfhat.api.onlineGame.ServerApi.GameSettings.

Why do you feel such a "cooperative grouping" is useful for: library authors, large APIs, application developers, ...?

In this case, it's a problem of large APIs that needs to be converted to very similar but yet different API.

1. Namespaces fix namespace pollution
2. They also provide an explicit and yet readable way of specifying what declaration is used in each specific place, without having to come up with new names for the declarations (like ServerApiGameSettings instead of ServerApi.GameSettings).

is FlowCollection a type of its own?

I think, no. You can imagine it as yet another package that can actually be imported. Whereas, standard packages cannot be imported. Or it's even better to imagine it as a stateless singleton that cannot be referenced as neither type nor instance (expression).

How do you write callable references to a method like collect?

I think, it should be the same way as for outer classes. I mean as it is a stateless object it's still an object. Like in the following example.

// That's how it is now.
object Singleton {
    fun foo() {} // Can be referenced as `Singleton::foo`.
    fun Bar.baz() {} // Cannot be referenced.
}

// That's how I propose to do the same with contexts.
namespace Namesapce {
    fun foo() {} // Can be referenced as `Namesapce::foo`.
    fun Bar.baz() {} // Cannot be referenced.
}

[serras]

I still don't see how this idea of namespace solves any of the problems. We tried something like this, and if you want to solve all the problems you still need to introduce some idea of "companion namespace", and still need a way to extend the members of the "companion namespace".

[CLOVIS-AI]

About using namespace, this could work, too. My concern there would be that we're bringing a completely new name into the table.

C# has namespace, Rust has crate. But to be fair, the namespace proposal could also be named package and wouldn't change by much, if the new name is the problem.

[SPC-code]

I strongly dislike current proposal. It completely discards the discussion of previous iteration, which I find a bit insulting.

The fundamental syntax is OK (though I liked scoped variant more), but naming is terrible.

It does not reflect any mental model at all. static is a java feature and it is more or less (probably less) natural to Java because in Java everything is a class. You can't declare something outside of the class so in order to do so, one had to declare something in class but not of class. Weird, but OK.

In Kotlin we cand declare things in file, in class, or event inside function scope. We have a hierarchy of namespaces. We even use it broadly in teaching and in common phrases like namespace pollution. We have companion objects as singletons tied to a namespace bound to a class name. Extensions are added to class namespace. Companion extensions are extensions to companion object namespace. It is obvious what is the mental model for this thing.

In the proposal not only, you introduce a completely new mental model, which you can't really explain without Java reference. Even more, you introduce TWO new models. T::type is a terrible choice. not only it includes additional term, it also clashes badly with T::class construct. Type and Class a treated like similar things by a Kotlin user. Now you say that those two are completely different things, you even had to clarify this to avoid confusion. I imagine how I will explain it to students. Look, guys, those two things are similar, but they have completely different meaning. Just forget one when you study another. Also, it is not a type function binds to. It is a namespace that is connected to a type.

Calling static a "scope" is another bad thing. Scope in Kotlin has a very specific and standard meaning. It is a lexical scope between { }. It does not even create a scope in this proposal. What you probably wanted to call it is a visibility modifier. But it is not a visibility modifier! It allows to use a namespace of parent class (also does not look good, but not terrible).

My proposal to fix things is following:

• Introduce a concept of namespace. Formally declare it as a part of language terminology. Including module namespace, package namespace (file), class namespace and scope namespace (including companion namespace and function namespace). I am not sure function namespace will ever be used for syntax, but it is a find mental construct, so who knows.
• Use namespace fun whatever() for class namespace functions instead of static fun whatever()
• Use T::namespace.whatever() for extension binding. The T::namespace could possibly have other uses in the future. Operating with namespaces. For example, namespace could be a separate entity for reflection and compile-time introspection (list all methods in a package, list all properties in a type namespace).

[serras]

Do we? I don't. Kotlin not having statics was one of the strong improvements over Java.

I think not everybody in the community shares this opinion; we see people in the Kotlin/Java space wanting more direct access to statics. I'm aware this is not a counterargument per se, but in the Design Team we have to aggregate not only what we hear at the KEEP, but also what we get from face-to-face discussions, user research, and input from developer advocates.

[SPC-code]

Just for the record. In my opinion:

• Companion objects are a great thing. Comparison with other languages is not convincing because Kotlin has some unique features. For example, context oriented (and therefore lexical scope oriented) design. Companion objects are great as identifiers and factories (in involves inheritance). But also as namespaces for code organization. Indeed, from performance point of view, creating additional type for namespace is not rational and it could be optimized, but otherwise companions are perfect.
• I agree with @CLOVIS-AI about lack of statics being a good thing (for me). It simplifies my understanding, and it simplifies the way I explain Kotlin to other people. I understand why Java needs statics (they do not have top level functions, but it always seemed ugly to me.

[CLOVIS-AI]

Also, the fact is that almost no programming languages, except Kotlin (after Scala), have adopted this feature (companion objects).

I'm curious, is this a big factor when discussing what Kotlin should be? I'm not aware of property delegation, interface delegation, context parameters, or the way suspend works being used in any other language, but I would still point to these features as essential to what Kotlin is, and would not remove them even if they don't seem to be popular elsewhere.

[zarechenskiy]

I'm curious, is this a big factor when discussing what Kotlin should be?

Yes, at the conceptual level, it's a major factor for us.

[FilipDolnik]

I think not everybody in the community shares this opinion; we see people in the Kotlin/Java space wanting more direct access to statics.

I will second this. I personally miss something like static in the language quite a bit. Don't get me wrong, the concept of companion objects is great because it allows for things that wouldn't be possible with just static. However, I strongly believe that there is room for the concept of static to co-exist with them.

Companion objects are overkill for most use cases (compared to static), and have several annoying problems that would be solved if the concept of static is also added to the language:

• Interop with other langauges like Java, Swift, etc.
  • I work a lot on KMP projects and therefore use Swift and Kotlin together a lot. I often run into a situation when it would be helpful to have a simple way to use static functions from Swift - that's not possible with just companion objects.
  • However, the problem is even worse with iOS devs learning KMP / starting with KMP. The objects and companion objects are just another complication for them / the absence of static is just another source of pain. However, compared to other problems of the interop, this one is solvable relatively easily so it would be great if it was solved.
    • It's also the case that people coming from other languages (not just Swift) are much more likely to quickly understand the concept of static than the concept of companion objects.
      • On top of that companion objects will become much less frequent if static becomes a thing because static is good enough for most common use cases.
• It's verbose to declare simple static declarations - especially private constants
  • Most often I just don't bother declaring a companion object just because I need to declare constants used only in the given class even if they could be const.
  • Similarly, what I like about the current proposal is the simplification of the syntax needed to declare the invoke operator.
• Not being able to declare extension on companion object if the companion object does not exist.

[SPC-code]

My ideas from previous discussion are summarized here: #348 (comment)

[edrd-f]

I was about to comment the same thing as @SPC-code on how this new version ignores the discussion on the previous proposal, where we can see there's a consensus around namespace being a much better option than static.

I also strongly disagree with using the ::<something> (be it type or namespace), as this syntax is used to reference a class member. It's very confusing to have yet another meaning for this. Maybe go with fun (namespace X).something() or fun namespace(X).something(). Different concepts deserve different syntaxes.

Lastly, I don't think there's any benefit in allowing namespace fun members given we already have companion objects. Let's remember the original request was to be able to add extensions to Java types and Kotlin types without a companion object. In summary, if the author can modify the class, they can add it to the companion. If not, they can add an extension.

For reference, this is the original request, which had most upvotes before it was renamed/reworked into this broader scope:

https://youtrack.jetbrains.com/issue/KT-11968/Research-and-prototype-namespace-based-solution-for-statics-and-static-extensions

[edrd-f]

@zarechenskiy this section was added on March 23, 2023 (commit).

@SPC-code wrote a summary with good counter-arguments on Sep 24, 2023: #348 (comment). The comment received 25 likes.

The central argument on both Elizarov's proposal and this one is that "static" is a known concept. However, if similarity with concepts in other languages was a concern when Kotlin was first designed, we wouldn't have companion objects. The idea was taken from Scala, sure, but Scala is far from popular. Hence, it's not a concept the vast majority of developers are used to. On the other hand, companion objects enable patterns that aren't possible with statics, such as implementing interfaces. I believe the trade-off is worth it.

The key thing is that the mental model must be simple, regardless of whether the concept is known or not, and static doesn't convey such a mental model. Furthermore, if first-class namespaces are to be added in the future, it will only amplify the confusion around what static means.

[zarechenskiy]

We're going in circles. If you're only talking about naming, OK, I see that. But if you're referring to an additional feature or a broader concept of namespacing, then, as it was written in the previous proposal and later in our experiments: we see is that such a feature ends up resembling our existing companion objects, just with a different name

On the other hand, companion objects enable patterns that aren't possible with statics, such as implementing interfaces. I believe the trade-off is worth it

And that's one of the core problems we see with the current approach. In the vast majority of cases, we don't need interface implementation, yet simply allowing it comes at a cost to the language. This proposal focuses on simplification and aims to cover the most common cases using simple constructs and more direct codegeneration that almost all target platforms support

The key thing is that the mental model must be simple, regardless of whether the concept is known or not, and static doesn't convey such a mental model

I wonder — why, though? In your opinion, what creates the complexity? The naming? Some unexpected behavior?

[CLOVIS-AI]

But if you're referring to an additional feature or a broader concept of namespacing, then, as it was written in the previous proposal and later in our experiments: we see is that such a feature ends up resembling our existing companion objects, just with a different name

What I don't understand is that, yes, that's the point? If you read the discussion in the previous proposal, that is explicitly the goal of most people in favor of namespace {}: to have a mental model that is exactly the same as companion object, except that it doesn't have a this, since the presence of the this is the main problem with companion object today.

You mentioned elsewhere in the discussion that you're searching for a lightweight solution. The problem is "companion objects require an instance". "A new thing that is like companion object but without an instance" seems to me like the most lightweight solution. Yet, each time you mention it, you say it is a downside without explaining why ("in our experiments"), as if it was self-evident. But that is explicitly what multiple people here are asking for.

[zarechenskiy]

If you read the discussion here, I mentioned that we'll cover it: #427 (reply in thread)

Also, Alejandro has already provided a preliminary and detailed answer to this: #427 (comment)

It seems to me that this discussion ultimately comes down to whether there’s a real need for better JVM interop. And to be honest, that’s not something we can decide based on the number of 'likes' under posts. There are many issues in our tracker that we can’t prioritize just because a few very vocal people feel strongly about them

[CLOVIS-AI]

@zarechenskiy Please clarify what you mean by "JVM interop". As I see it, all alternative proposals described in the discussion of this KEEP have the same "let's introduce a clear one-to-one way to declare a static JVM member", which is how I would define "JVM interop". However, each time you mention as a rebuttal that "there is a need for JVM interop", so I assume there is a communication problem here and you mean something else than I do?

[zhelenskiy]

I strongly support @SPC-code about most of his points.

However, I have to mention several minor issues in his argumentation.

1. companion objects are bad example of scopes. The regular scopes work this way:

   private val a = 3
   // b is NOT visible here
   class A {
       private val b = a
       // a is visible here
   }

   while companion objects work the opposite way:

   class A {
       private val a = b
       // b is visible here
       companion object {
           private val b = 4
           // a is NOT visible here
       }
   }

2. I'm not sure if namespaces can be extended to static namespace interfaces.
3. Formalising the word namespace would either narrow its meaning or make it too complicated for most of the people.

[SPC-code]

A good argument about companion object. Indeed, it does not behave as a nested scope. Actually, the good solution would be to completly move namespaces out of the class body. Something like:

class MyClass{
}

namespace MyClass{
}

I would do just that in my code (similar to what Rust does). But it probably would be too much to ask of everybody. So namespace fun is a good compromise.

As for hardness of defining namespace, I do not agree. Yes, defining a fundamental concept is not easy, but we are talking about a thing that already exist. Something like "a set of rules to resolve a behavior (method or property) or type base on its signature bound to a specific lexical scope". It could be further narrowed by adding optional scope inheritance.

[serras]

Let me add a different view point which I think is being somehow ignored in the discussion: we really really care about providing access to the "static" ideas in the underlying platforms. Java, JS, Swift, almost all the platforms we compile to or want to interoperate to have such a notion; and sometimes require using a static method in particular places. The current solution: defining something in a companion object and annotate it with @JvmStatic @JsStatic is less than optimal.

On that topic, any proposal which does not directly map statics in Kotlin and statics in Java should come with a solution about how to reflect statics in Java coming from dependencies. In this KEEP we say "the current way is done in the compiler is OK", and simply extend this idea to defining static members.

[zhelenskiy]

What do you think of #427 (comment) then? I propose to get the same functionality without introducing barely the same as existing language feature. It solves the problem for top level case, while for companion case there can be static, as it better describes the class members. I claim that because non-static methods are also in the scope of their class, so calling them namespace or scope might be confusing.

[CLOVIS-AI]

How is namespace MyNamespace different from object MyNamespace?
I mean from the users' side.

namespace MyNamespace provides better Java (and other platforms) interoperability because it is guaranteed that anything inside of it will map one-to-one to a static member on the platform (if the platform has such a concept). This is the benefit for the users, as mentioned in the motivation for this KEEP. Another difference is that it cannot use the keyword this, as there is no instance associated to a namespace.

Another benefit is that it is trivial to convert between object Namespace and namespace Namespace if no instance is needed, and the other way around if an instance becomes needed. Since it is expected that the vast majority of companion object will become static/namespace (that's the motivation for this KEEP, after all), having them work similarly is very important in my opinion. For library developers this would be an issue because of binary compatibility, but for application developers, where binary compatibility doesn't matter, this makes the migration trivial.

Another benefit is that it supports all namespacing use-cases in Kotlin today, which the static proposal does not. Currently, top-level object can be used as a way to namespace declarations. The static proposal only supports removing the instance of companion object, not regular object. If I had a pure namespacing object;

object Namespace {
    @JvmStatic
    fun foo(): String
}

and I wanted to take advantage of this new feature to avoid the pointless instance, I would need to migrate to:

class Namespace private constructor() {
    static fun foo(): String
}

This doesn't feel like Kotlin at all. The point of object was to have a dedicated keyword for a very common pattern, and with this new proposal we are losing that expressiveness.

Otherwise, the namespace proposal does support this use-case:

namespace Namespace {
    fun foo(): String
}

This feels much more like Kotlin. We have a use-case, and a solution for it, which is the same design principle behind value class, data class, enum class, etc.

[CLOVIS-AI]

Because otherwise you have two features that do exactly the same.
But you can use object as a namespace and nothing will change for the user. Why would we introduce a reduced object if the regular object already exists?
Ok, can you explain what object/package cannot do, what namespace can?

I'm very confused by your point here, because to me the answer for all of these questions is written in the KEEP itself. The "Motivation" explains that:

• There is static in other languages, but not in Kotlin
• So far, we haven't needed static in Kotlin because we have object, but as time passes some of the differences have become too large and we'd like something that is closer to static for performance/interop reasons, namely:

In order to create an extension callable accessible through the class name, you have to extend the companion object type. But if the class does not have such an object — it was not introduced by the developer or comes from a platform where no such notion exists — this becomes impossible.

This is made possible by namespaces for the same reason it is made possible by static: they don't have an instance, therefore there isn't a problem when declaring it externally. That is also the first difference between namespace and object: you can declare a namespace extension on a class even when it doesn't declare a namespace.

There is a mismatch with the concept of static member from the main platform Kotlin runs on (namely, the JVM). Kotlin features a @JvmStatic annotation, but its behavior is not always the preferred one. In particular, the compiler still keeps a "copy" of the function in the object.

namespace becomes a marker clearly visible in code that the generated code will mark what a pure utils-class would be in Java. This is the second difference with objects.

It is not clear where some elements of the language live; the main example being enumeration entries.

They live in the namespace of the enumeration.

---

I don't understand why you keep bringing up that namespace and object are too similar, when the conceptual differences are exactly the motivations for this KEEP, so to me they seem to be exactly as different as they need to be. Or maybe you think they are too similar in terms of syntax? Personally I would think of that as a pro, not a con: it makes it easier to migrate from one to the other, and makes it clear that they are two sides of the same coin, two ways to provide the same feature with different tradeoffs.

Kotlin has objects and companion objects, that is simply a fact. They have limitations, and we may need a way to avoid these limitations, that is a fact. Many languages have static, that is a fact too. However, not a single language has both static and companion object, which are extremely similar, and I think there are very goods reasons for that. It seems to me that there is enormous value for the longevity of the language that new features interoperate well with old features, so if we have to have two different features that are very similar, let's make it obvious with syntax, so it's easy to teach people.

When someone asks, "what is the difference between static and companion object?", the answer is quite complex, and involves explaining what static means ("things can be bound to a class itself instead of to an instance"), the reason we have object ("static is very different from everything else in the language because it cannot inherit members, it cannot be in a variable, it cannot be top-level, etc, so we introduced a different concept object which behaves much more like a class"), what companion object is, the reason we have static anyway ("companion object is a instance and static isn't"), and the pro/cons in the different syntax ("static is shorter when declaring a single thing, companion object allows grouping multiple related members").

When someone asks, "what is the difference between namespace and object?", the answer is "namespace guarantees that everything inside is compiled to static methods on platforms that support it." Everything else that makes them different (e.g. they're not a type, can't be expressed as a value, can't implement interfaces, can't have toString, can't be data…) derives logically from that simple sentence.

[CLOVIS-AI]

I think @JvmStatic modifier on object is totally sufficient. For other platforms, there is a closed world, so we can change how it is compiled in case there are no supertypes. There is no need to create a classifier that behaves completely the same way as an already existing one.

This rebuttal applies in the exact same way to namespace as it does to static. If @JvmStatic companion object is indeed sufficient, then the only useful part of this KEEP is the fun String::type.foo() syntax, and everything else can be removed.

Actually, that would further your point about searching for a more lightweight solution. It would not be my preferred approach, but it does solve the problems we have at hand in a very simple way, leaving the door opened for actually introducing more important concepts in the future.

[SPC-code]

I completely agree with @CLOVIS-AI. Namespaces and objects are similar, and it is great. I like this formula: object = namespace + type instance. There could be a namespace without associated instance. There could be instance without namespace. Object "inherits" all functions of a namespace but adds more. So, it should be similar.

[SPC-code]

Additional thing, I forgot to mention yesterday (actually it is @lounres, who mentioned it in the community discussion). Companion.invoke is currently considered antipattern. It is totally superseded by factory-functions. Companion builders are valid things unless they use invoke. It is understandable that the case must be covered because Companion.invoke is still used in a lot of places, but there should be mention that it is discouraged.

[zhelenskiy]

I don't remember exact cases, but I have met the situation with falsh constructor when one of them accidentally shadows another. And it worked with operator invoke.

[SPC-code]

You reference documentation earlier. Companion.invoke is not a recommended practice now.

[zhelenskiy]

It doesn't change my point

[edrd-f]

Factory functions can't call private constructors, though. Companion.invoke can.

[zhelenskiy]

As far as I understand, one of the use-cases for namespaces is the ability to provide a partial qualified name. Currently, it can be done via objects, but they lead to storing everything in one file, which is bad.

object A {
    object B {
        val a = 3
    }
}

import A.B

fun main() {
    println(B.a)
}

The reason to do so is escaping namespace pollution and not specifying potentially long full qualified name at the same time.

This feature itself can be done without introducing new concepts and keywords at all. We can just allow importing packages which already serve as namespaces, so there would be no need to create yet another namespace analogue.

Using namespace inside classes is IMHO misleading because regular instance methods are also i the namespace of the class.

---

Another thing that object has but package has not is the ability to place several things in one file. That might be useful if you have several small packages with one file containing only a couple of lines each.

A solution here would be the introduction of package blocks.

package a.b

package c {
    package d {
        val e = 3 // fully qualified name is a.b.c.d.e
    }
}

There even shorter form can be introduced.

package a.b

package c.d {
    val e = 3 // fully qualified name is a.b.c.d.e
}

---

If you see any other use-cases for namespaces, @SPC-code and @lounres, tell me.

[zhelenskiy]

The last thing is definitely a different issue.
For the second case, can you provide a sample of your code, please?
For the first point, I think the default behaviour can be easily configured with an annotation/modifier or in IDE, because the same thing exists for namespaces as well. The good example is std in C++.

[lounres]

The last thing is definitely a different issue.

Yeah, sorry. "Накипело."

For the second case, can you provide a sample of your code, please?

Here is what I mean. Don't # 1 (namespace pollution):

interface KoneList<out Element> {
    ...
}

fun <Element> buildKoneList(...): KoneList<Element> { ... }

Don't # 2 (bloated KoneList declaration; could be OK if build was private):

interface KoneList<out Element> {
    ...
    companion object {
        fun <Element> build(...): KoneList<Element> { ... }
    }
}

Don't # 2.5 (the same as # 2 but for statics):

interface KoneList<out Element> {
    ...
    static fun <Element> build(...): KoneList<Element> { ... }
}

Do (but only if KoneList contains a companion object; KoneList still has to contain something...):

interface KoneList<out Element> {
    ...
    companion object
}

fun <Element> KoneList.Companion.build(...): KoneList<Element> { ... }

Ideally do (with statics; now KoneList does not contain a thing that language demands from you):

interface KoneList<out Element> {
    ...
}

fun <Element> KoneList::type.build(...): KoneList<Element> { ... }

(Using current proposal's syntax despite disliking its naming (only naming!)).

For the first point, I think the default behaviour can be easily configured with an annotation or in IDE, because the same thing exists for namespaces as well. The good example is std in C++.

Sounds good. I think it would be good if you highlight it in your initial comment.

[Peanuuutz]

Your proposal sounds interesting and could be a potential replacement for standalone namespaces. But right now it has a few problems:

1. Declarations in package blocks are still top level, which means they have the same global namespace pollution problem.
2. The interop (in any platform) issue still remains, and probably worse. If we propose package blocks, how would Java call their members? Would it be some kind of XxxKt_a monster? And if you say "just use @JvmName", then isn't it the same as @file:JvmName we do today? Or if you use objects instead, you still need to add @JvmStatic, or fall back to use a class with only static members because it's only supported there. This feels like a half-solution to the "companion object vs. object" pair IMHO.
3. Partial package import may be a solution to the above problem, but it also raises the following questions: a. how do you specify the auto-complete rules? Note that in a common JVM project, the package hierarchy can be at least 4 levels deep, and there are a LOT of clashing names like util, impl across different dependencies; b. packages are named lowercased. Right now if we see foo.bar, we would assume foo is a variable, but now it's a different story. It may be a big change to UX and code style.

[zhelenskiy]

1. I mentioned a modifier which would can be used for package to mark that it must be imported explicitly. Something like explicit package or namespace package.
2. I expect a package block A in file B with package C to behave as a file B in C.A.
3. The same question for namespaces.

[Peanuuutz]

1, 2 are OK to me and 1 could be an answer to 3.a, but for 3.b they're definitely not the same. Namespaces are named uppercased just like objects or classes with only static members in Java.

[lppedd]

It feels like this is going to end up like the previous proposal. Basically, we seem to have two perspectives.

• The language designer perspective, which summarizes to:

  • we want to solve a bunch of interoperability issues by introducing a real static concept into the language
  • we want it as a lightweight feature as it solves a very specific problem

• The user perspective, which summarizes to:

  • we don't want to solve only a very specific problem
  • we don't want to port the static concept to Kotlin as it's used only in languages like Java or C++, and Kotlin is a new playground
  • we want namespace instead, as it's a broader concept that can cover more areas and evolve further. Example in a comment.

So how do we tackle this difference in ideas for the future of the language?

In this discussion we have also seen counter-arguments to the user perspective.

• namespace-like behavior can be obtained already with object.

  object A {
      object B {
          val a = 3
      }
  }

  To which I would reply that this is not how it should be done, for the simple reason semantically objects represent singletons, not pure containers for grouping. Yes, a dozen blog posts tell us that's how to namespace (or scope, as you prefer) declarations. But it's really not an ideal alternative.

• namespace-like behavior can be obtained with packages.
  I mean, wish we at least had the concept of package-private! And even if you make packages importable to qualify references:

  // hello.kt
  package a.b.c
  
  fun hello() = ""
  
  // main.kt
  import a.b
  
  fun main() {
    println(b.c.hello())
  }

  You would end up polluting the global namespace. The fact we have free-standing functions and properties but no real way to namespace them means we end up with dozens of symbols popping up every time we invoke code completion, which is extremely suboptimal UX.

Edit: and before someone comes up with the idea of using yet another annotation to change the behavior of the language, please don't. The amount of annotations is already ridiculous, let's not complicate it further.

[lppedd]

Well, you can do it in file top level, forbidding it for the namespace within the file would be inconsistent and weird.

Why would it be inconsistent? Generally speaking top-level declarations are meant to be globally visible.
Namespace solves this problem by giving us more control on how we want declarations to be exposed, and that's exactly why we're using objects to do that now, although we are aware they're not meant to do that.

So this way you end up with another package alternative

But it's not a package alternative. Namespaces can be declared inside packages, and referenced by qualifying them with their package name if necessary.

Annotations as any instrument is good when applied correctly

I agree. But what I'm saying is we already have to use abundant annotations, and bringing another one to the table worsen the coding experience. Applying annotations is not a fluent experience as they're generally applied after declaring the symbol where we want them applied.

I don't understand what you want to say by this

There seems to be resistance to what the users want. I've read the entirety of the previous (now closed) discussion and it's surprising how many people came up with namespaces. I don't think it's a coincidence when a big chunk of people agree on a concept, it simply means it's a good idea that should be explored. But this proposal goes straight back to static.

[zarechenskiy]

I don't think it's a coincidence when a big chunk of people agree on a concept, it simply means it's a good idea that should be explored. But this proposal goes straight back to static

We explored this approach, but it quickly fails once additional features are introduced. If we limit it to its core functionality as with statics, the only remaining difference is naming, and we believe "namespace" doesn't suit our main use cases. That said, let us gather the feedback here and see what we can do. We’ll follow up with a more detailed design exploration of namespaces and include our findings in the KEEP

[zhelenskiy]

Why would it be inconsistent?

Because inner scopes tend to have more functionality than their outer scopes. E.g. function can access everything in the outer scope AND variables.

So, it is strange that you do this way:

val x = 3 // Allowed as top level in JVM.
namespace A {
    val y = 4 // COMPILATION ERROR
}

But it's not a package alternative. Namespaces can be declared inside packages and referenced by qualifying them with their package name if necessary.

Just for your understanding, I'm not against namespaces in any name they can be (package with modifier/new keyword, etc.). I find it misleading and confusing to use the modifier for static functions as regular functions are also in the namespace of the defining class. So, this way the scope of this feature (not namespaces) is narrower and the word static fits more, as it is not ambiguous.

But what I'm saying is we already have to use abundant annotations

TBH, I don't see it beyond Spring. Also, I'm not really against adding a modifier explicit/namespace or even adding a standalone namespace keyword. I'm against joining the concepts of namespace and statics.

There seems to be resistance to what the users want. I've read the entirety of the previous (now closed) discussion and it's surprising how many people came up with namespaces. I don't think it's a coincidence when a big chunk of people agree on a concept, it simply means it's a good idea that should be explored. But this proposal goes straight back to static.

The number of people who want ternary operator in Kotlin is also huge, but that does not mean that we should add it to the language too, right? Otherwise, we end up with a garbage dump. We need to consider the features if they fit the language or not.

[serras]

@lppedd thanks for writing a summary of the two views. However, I would not call them "designer view" and "user perspective", in that those users are just those discussing in this thread. Unfortunately, we see that lots of our users really want a better interoperability story with Java, and the namespace feature mentioned here doesn't really account for that possibility.

[lppedd]

Thanks @serras. I understand the interoperability story and I don't want to sacrifice it if possible. However, isn't the language moving in that direction already? For example, it is not possible to nicely represent rich errors in Java.

What I would like to read is what @zarechenskiy suggested, some kind of write up that explains why namespace is difficult to have in Kotlin. One of the questions would be "why can't we map a class' namespace to JVM statics?".

It's just that once something like this is in the language it's basically impossible to get rid of it, so I prefer more discussion before getting the feature.

[hfhbd]

As a user, how do I call a static function with a receiver?

package my.package

object Greeter {
  fun hello(name: String) { ... }
}

class ClassRoom {
  static fun Greeter.helloFolks() = hello(name = "folks")
}

If I am only allowed to call it from other static functions inside ClassRoom, the function helloFolks is in practice private, isn't it?

[frozenice]

I guess type extensions are an example where you could call it:

fun ClassRoom::type.useFolksFor(greeter: Greeter) = greeter.helloFolks()

If you declare helloFolks as e.g. private then it wouldn't be accessible in useFolksFor.

[hfhbd]

Yeah, so it is only callable from a static context inside ClassRoom. IMHO not really useful and it could be solved via a private (non static) function instead.

[serras]

@hfhbd you have to ways to call it

• If you are inside the class itself, you can call it directly, as you do there
• Otherwise, you can re-import it to top-level

package my.package

import ClassRoom.helloFolks as classRoomHello

// same object and class as before

val h = Greeter.classRoomHello()

[hfhbd]

@serras Honestly, I still don't get it when Greeter is also a class.

[serras]

You can already write extension functions within other classes, whether the receiver is a class or an object doesn't change that. But this is orthogonal to the member itself being static or not.

package my.package

class Greeter {
  fun hello(name: String) { ... }
}

class ClassRoom {
  val groupName: String

  fun Greeter.helloFolks() = hello(name = "people from $groupName")
  static fun Greeter.helloFolks() = hello(name = "folks")
}

[SPC-code]

Actually, you do not have to introduce anything static-like at all.

There are two problems that this KEEP solves:

1. Statics on jvm without annotations.
2. Allow extension on type namespaces without companions.

Point 2 could be achieved with ::namespace/::static/::whatever syntax for extensions without any other changes. Actually, it is much more consistent than any other things discussed here because it does not violate lexical scope rules.

Point 1... is it needed at all? The whole Ktor codebase has only 15 places where @JvmStatic is used and most of them are in tests. So the whole feature is for a thing that you use like never? Event in cases, when you do, and even if you hate annotations, you can use :: notation for that, assuming it is always converted to static.

class MyClass


fun MyClass::namespace.main(){
//
}

It actually looks much better than main method in a companion or in a body of a class. It is a separate construct as it should be.

[zhelenskiy]

Extensions functions don't break encapsulation as they don't have access to the private class members (beyond your request). So, the point is still relevant.

Yes, private members are necessary to keep invariants in basic API that is used in extensions.

Companion objects shouldn't be used besides cases when they inherit something. In all other cases they bring nothing but complications and should be highlighted with a warning.

[SPC-code]

I would not recommend migration from companion to statics in current proposal in case of more than one method or property in companion. It decreases readability. In case of companion all those behaviors are grouped in a scope with defined rules. In case of separate methods, they could be mixed with regular methods. I have more than ten years of Java experience and I know how chaotic it is.

I would rather use top level privates. If you do not want them as privates, but to be placed in the namespace of a class... well, this is a namespace discussion all other again and you said you don't want to address it.

[zhelenskiy]

@SPC-code don't you have the same problem with suspend functions? They are declared not in suspend object blocks and can be called and from other suspend functions. I don't like the idea of grouping because I would place the functions close to there usages inside the class, because now I have to jump between several places in the file.

I wouldn't refuse supporting OOP, if you don't like, there are still people who follow its principles.

[Peanuuutz]

But most static functions are used outside the class. It's more preferable to make them related to the class but not mixed into it.

Could have both TBH, I'm personally not against having both. They have their own scenarios. It could also be that you can define multiple static blocks. I don't see any issue why not. They're not objects anyway.

FYI in the previous issue more people voted block syntax.

[zhelenskiy]

But most static functions are used outside the class. It's more preferable to make them related to the class but not mixed into it.

Could have both TBH, I'm personally not against having both. They have their own scenarios.

That is actually my point I want to get across

[serras]

Instead of answering different threads on small issues, I'd like to discuss the overall namespace feature we considered during the design, and why we think the current proposal with static is better. Note that the argument builds on the fact that you care about the same goals that we do, that's it:

1. We want a way to extend the static/class scope without limitations, like we have with companions right now;
2. We want an easy mapping to statics in Java, because those are needed for interoperability purposes.

One of the alternative designs we considered is having some sort of namespace construct similar to objects:

• From the language perspective those namespaces have no instances -- it's arguable whether you can even talk about their "type" at all, but this is not so important here;
• From the compilation perspective, they are classes with private constructors and every member is marked as static in the underlying platform.

At this point you don't really fix any of the problems there, you need to have some kind of "companion namespace" similar to companion objects. If we want to fix problem 2 (interoperability with Java) we need to "lift" the members of the companion namespace into static members.

class Foo {
  companion namespace {
    fun bar(): Int = ...
  }
}
// compiles to
class Foo {
  static int bar() { ... }
}

This also causes some problems in the model, because the same code is viewed in two different ways from the reflection perspective: within Kotlin you would like to say that the members are part of the companion namespace, but from the Java point of view they appear as static members of the underlying class. However, I think the main problem comes at a conceptual level: if you want to compile to static members in Java, that means that the members in the companion namespace cannot access instance members of the enclosing class. This means that companion namespace is lexically scoped to the class, but actually have additional restrictions over what can be accessed and what not. At this point, it's unclear that if you care about the problem of Java interoperability this solution is going to be more satisfactory than having a companion object with some annotations.

There's also an additional problem of nesting here. People around here may like the nesting of companion objects, but it is unclear why we need to nest something which is in no way nested to an instance or a class. My personal opinion is that static members live on a parallel scope to instance members, and thus should be declared also in "parellel nesting".

Still we haven't talked at all about how we solve problem 1 (extend class scope). The key point here is that we need to assume that every class has some kind of companion namespace if we want to be able to extend it. It seems like the only possibility is to have something very similar to what the KEEP does, except that with a different reasoning to get there.

fun Foo::namespace.f() = ...

At this point, you may also ask why it's not simply better to just assume that every class has a companion object instead. After all, we could also have special syntax to mean "the companion object or a virtual one if it doesn't exist".

fun Foo::companion.f() = ...

In any case, it seems that for "extending static/class scope" the only available solution is to provide a direct way to do this. At this point the question is more about aligning the conceptual model than the syntax and feature that the users see.

In summary, trying to design namespaces to fix these problems ultimately require some sort of companion namespaces, and additionally syntax to extend those. However, you end up shoehorning a particular compilation strategy if you care about Java interoperability.

[Peanuuutz]

However, I think the main problem comes at a conceptual level: if you want to compile to static members in Java, that means that the members in the companion namespace cannot access instance members of the enclosing class.

I'm confused. Why not? In Java you can access, no?

final class Foo {
    final int i;

    static void bar() {
        var foo = new Foo();
        IO.println(foo.i); // Valid
    }
}

And in my imagination this translates to:

class Foo {
    val i = 0

    companion namespace {
        fun bar() {
            val foo = Foo()
            println(foo.i)
        }
    }
}

Conceptually, it's a companion to the class, so it makes sense that all the members are shared. Namespace members can access private instance members and true for the other way. Personally I don't see why it can't be the case given how companion objects behave right now.

[CLOVIS-AI]

if you want to compile to static members in Java, that means that the members in the companion namespace cannot access instance members of the enclosing class. This means that companion namespace is lexically scoped to the class, but actually have additional restrictions over what can be accessed and what not.

That's true, but I don't understand what makes this a problem. After all, this is already how Java and Kotlin behave;

Java:

class Foo {
    public String foo = "foo";
    public static String bar = foo; // Illegal
}

Kotlin with companion object:

class Foo {
    val foo = "foo"
    companion object {
        val bar = foo // Illegal
    }
}

Presumably, this same behavior is expected with this KEEP?

[CLOVIS-AI]

There's also an additional problem of nesting here. People around here may like the nesting of companion objects, but it is unclear why we need to nest something which is in no way nested to an instance or a class. My personal opinion is that static members live on a parallel scope to instance members, and thus should be declared also in "parellel nesting".

I won't argue that it's good that the nesting is this way—I don't particularly find it problematic but I can understand that other people do mind it. However, let's recognize that it is a common thing and not something Kotlin created, and that it itself has roots in Java interoperability: this is the behavior of nested classes (Java: static class), which are very common too.

Even without talking about companion objects, nested classes are used quite frequently in Kotlin, so I would expect the vast majority of users to be familiar with this behavior, and wouldn't be surprised if a new feature behaved similarly.

At the very least, when teaching Kotlin, I've never had a student be confused by this, which isn't the case for many other features, so maybe I'm biased.

[CLOVIS-AI]

This also causes some problems in the model, because the same code is viewed in two different ways from the reflection perspective: within Kotlin you would like to say that the members are part of the companion namespace, but from the Java point of view they appear as static members of the underlying class.

Is that a big problem? The reason we have a dedicated :kotlin-reflect is because both languages tend to see the declarations differently, no? It's already often the case that reflection views symbols differently, especially everything related to properties.

[CLOVIS-AI]

fun Foo::companion.f() = ...
In any case, it seems that for "extending static/class scope" the only available solution is to provide a direct way to do this. At this point the question is more about aligning the conceptual model than the syntax and feature that the users see.

100% agree.

I don't think it's a coincidence that the alternative proposals (namespace/static/etc) converge to having that specific feature.

• It's something we have all needed at least once
• There is currently no way to do it
• It's a very simple solution for a very simple problem
• It doesn't impact the rest of the language nor does it impact the way we learn about the language

[CLOVIS-AI]

Could the Motivation section be clarified?

Static members have no state, which makes them great for utility functions. The usual StringUtils in every Java/C# project is a witness for that.

This is already supported by extension functions.

By including static members, a class also works as a namespace. One nice example is List.of in Java, which fits the general pattern of factory.

This is already supported by top-level functions like listOf() and List().

In order to create an extension callable accessible through the class name, you have to extend the companion object type. But if the class does not have such an object — it was not introduced by the developer or comes from a platform where no such notion exists — this becomes impossible.

This I do understand is a problem currently.

There is a mismatch with the concept of static member from the main platform Kotlin runs on (namely, the JVM). Kotlin features a @JvmStatic annotation, but its behavior is not always the preferred one. In particular, the compiler still keeps a "copy" of the function in the object.

This is already supported by using @file:JvmName() and top-level functions, which are compiled to true JVM-static methods. For the use-case of utility classes in particular, this already allows generating exactly the same binary API as the equivalent Java classes, with no intermediate classes.

It is not clear where some elements of the language live; the main example being enumeration entries.

This is the strangest goal for me. Instead of aligning enum entries to the rest of the language, this proposal is adding an entirely new concept to align enumeration entries, from the starting point that they are the odd ones out.

Overall, the "companion object requires instantiating a long-lived object" problem is the only motivation I understand here, and it seems to be that there is probably a much simpler solution than introducing the entire concept of statics just for that.

[serras]

This is already supported by using @file:JvmName() and top-level functions, which are compiled to true JVM-static methods.

But that does not support adding static methods to classes, which is the main use case for static methods in this proposal. With @file:JvmName you can only get static methods in a different class.

[CLOVIS-AI]

data class Vector(val x: Double, val y: Double) {
  static val Zero: Vector = Vector(0.0, 0.0)
}

val Vector::type.UnitX: Vector get() = Vector(1.0, 0.0)
val Vector::type.UnitY: Vector get() = Vector(0.0, 1.0)

I don't see this point being mentioned, for ease-of-learning, this two should definitely be named the same. If the keyword stays static, then it should definitely be val Vector::static..

[CLOVIS-AI]

@xvbcfj I disagree, I think static in front is the same as a top-level function. See this comment.

"Ambiguity in naming" says:

All possible cases are summarized below;

but the example doesn't contain an example with ::member. Could one be added? Also, an example of referring to a method in a companion object.

[xvbcfj]

I disagree, I think static in front is the same as a top-level function.

I haven't gone through the KEEP in depth, but i don't understand why this has to be the case? static fun f is top level, static fun SomeClass.f is not. this is the most simple mental model since everything else related to extensions work the same.

[serras]

The problem is that you can write static extension functions, and functions which extend the class scope inside other classes, so you need to disambiguate between.

class Example {
  static fun Foo.f() = ...
  fun Foo::static.g() = ...
}

[hfhbd]

@serras can you please give some more details between these examples? I really don't get it.

Okay, got it, f needs an instance of Foo, g does not.

But IMHO, static functions should never have a receiver (aka this), because they are static so allowing this breaks the mental model when coming from Java.

[serras]

But IMHO, static functions should never have a receiver (aka this)

But Kotlin functions have potentially two receivers, so each of them may be not present, an instance, or static (or at least this is the model the KEEP brings to the table).

[CLOVIS-AI]

I'm in favor of forbidding static fake constructors even more so than regular operators.

Regular operators are problematic in static context because they often imply state. getValue, plus, plusAssign all implicitly require some kind of entity on which the operator is executed, which makes no sense for static members, so I agree they shouldn't have operators.

However, that is even more so the case with invoke. invoke represents that an object can be intrinsicly called as a function. Static members are not even a part of "something", so it is meaningless to say that that "something" is a function.

Fake constructors using invoke is only a pattern because IntelliJ is bad at static-importing a method of the same name as the class from its companion object. If IntelliJ recognized the pattern and imported it correctly, invoke wouldn't need be used for this purpose, and there would not need to be an invoke operator at all in static context.

And yet, invoke is also viewed by many as an anti-pattern because tooling support around it is so poor. In IntelliJ, it can only be accessed by right-clicking on the ending brace, in Dokka and in type hints it appears as completely uncorrelated function, etc.

If there is a need to have fake constructors at the language level, something like fake constructor(foo: String) { /* … */ } would be a much better solution that bringing yet another feature into a static world. This also joins together the collection literals proposal: a lot of the complexity and restrictions (awkward syntax of the operator of, cannot be extensions, overload rules) clearly point to them not being an operator at all, and instead being some new type of fake constructor. Is this direction being analyzed?

[zarechenskiy]

Static members are not even a part of "something", so it is meaningless to say that that "something" is a function.

Sorry, I didn't get your point. Static members are part of the static scope of a type. Type extensions are also part of that static scope.

Fake constructors using invoke is only a pattern because IntelliJ is bad at static-importing a method of the same name as the class from its companion object

No. It's a pattern because it allows attaching a 'constructor function' to a type, not to its name. With factory constructor functions, type aliases stop working. For instance, for typealias StringList = List<String>, I can't invoke the factory function List from the stdlib anymore: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/-list.html, and so on

And yet, invoke is also viewed by many as an anti-pattern because tooling support around it is so poor

Here I do agree, and this is something we'd love to improve, both in the tooling and in the language, to make importing extension functions easier

[serras]

After some more direct discussion, it seems to me that there are (at least) two camps on the whole "namespace" idea. This gives us three broad options:

0️⃣ Keep the same KEEP

• Maybe with small variations like nested static blocks, not allowing static operators, or renaming ::type.

1️⃣ Keep almost the same KEEP, but rename "static" with "namespace"

• Maybe with small variations like nested namespace blocks.

2️⃣ Introduce a notion of top-level namespace, and use "companion namespace" as the way to attach members at the class level (which I described here)

Just to be clear, could people here emoji-respond in which camp they are? Or if their position is not being (roughly) represented here, how does it differ with all three of them?

[serras]

I find these results quite surprising, to be honest. I wrote in this comment a rebuttal about why option 2️⃣ is not a viable option.

Maps to statics without any annotation

Changing the compilation strategy is completely out of the table, here, unfortunately, as would mean breaking backward compatibility.

[lppedd]

I think most of us interpreted it as "it's more complex, it has downsides for compiler internals, but it's feasible". And again I believe most of us would prefer to introduce a single concept, instead of static + something else as a namespace-like follow up (that you wrote you're not against to, which is great btw).

[Peanuuutz]

I didn't mean "just change obejct to namespace and everything will be fine". I know that will break compatibility. I was saying for new code it's more preferrable. Also we could introduce an annotation for smooth migration. Maybe the std won't be able to fully migrate, but for others it's doable.

[SPC-code]

@serras I reread what you wrote in your comment and what I get from it is following: "we can add namespaces block, but it will have (at least at the beginning) so many limitations, that it will be no better than companions with annotations". The thing is "companion object with annotations" is all right. It currently solves all problems with platform statics. Not perfectly, but it is not important enough to introduce whole new language feature to fix. Nobody cares about namespace nesting right now. Maybe in future but at the moment, you can just forbit all those things.

What people really want (please check youtrack issues and discussion) is to be able to add companion-like extensions for classes without companion and for java classes. It could be done by adding namespace blocks. But if it is too hard to design, you can just add Class::namespace (or whatever) to solve the problem at hand without additional complications. Then it is possible to add more complicated features on top of that with much more synergy between them.

[FilipDolnik]

For me it's something in between the 3 options.

I don't have strong objections to the current proposal as it solves use cases I have for this feature, namely:

• Better interop with Swift and Java (by being able to express the concept of static declarations)
• Reduced boilerplate needed to declare the equivalent of static declarations (by having to wrap them in the companion object).
• Being able to declare static extensions in classes without companion objects.

I agree that the ::type syntax can be confusing and I wouldn't complain at all if it was changed - if we can find a better name that is.

I don't care too much about changing the naming from static to namespace though I don't understand the reasoning of namespaces being "easier to grasp for beginners". Maybe it might be for complete beginners - can't say much about that, but static is very well known name for this feature and people coming from languages like Java and Swift know it by that name. Both Java and Swift are common previous languages for Kotlin beginners who already know some programming language. So at best there is a trade-off in my opinion.

Also, I didn't even consider that this feature is about namespaces before reading the discussions above, because for me namespaces vs. static are something completely different (for example in C++) and Java and Kotlin have packages as a "sort of" equivalent feature of namespaces. So this might be a bit confusing for some people as well.

I wouldn't mind having syntax for grouping multiple static declarations in a block like we have with companion objects (but probably without the companion keyword), but I would like to still have a way to declare a single declaration without having such block using something like static fun foo() {}. If it's not desirable to have both options, then I would much rather have the single declaration one like in the current proposal.

As for static operators (like invoke) - this feature is one of the highlights of this proposal for me, so I would definitely like to see it being implemented. It cuts down so much of the current boilerplate and makes it easier to move invoke functions next to the constructor where they logically belong - like convenience initializers in Swift.

As for having top-level namespaces - I think that having some shortcut for

class Foo private constructor() {

	static fun bar()
}

for example as:

namespace Foo {

	fun bar()
}

could be benefical because I have a feeling this pattern will occur a lot if it's not added right away and it would align with the Kotlin goal of reducing boilerplate.

That being said, I think that having these named namespaces (with namespace keyword) and the static keywords at the same time is also something to consider as an option. It would map better to how these concepts work in other languages than if you have namespace fun foo() {}. Though in that case I wouldn't probably add companion namespace as that would be quite confusing.

[zhelenskiy]

I see many opinions which point only at one side of the situation. So, I decided to make an overview of it.

Status Quo

companion object is a great feature with several different applications and several problems.

Applications

Totally there are 1.8M usages of companion objects.

By categories:

Name	Inheritance	Count	Usage
-	-	1.7M	As statics replacement
+	-	8.6K	As statics replacement but with better name for extension (and sometimes better Java name, but the companion members are often still @JvmStatic)
-	+	44.8K	As static factory implementation (usually by delegation) Metadata storage (by delegation) Static interfaces and abstract classes Default implementations (e.g Modifier) Logger
+	+	25.6K	The same as above, but with better name to share intent Typesafe keys Plugin implementations

@JvmStatics are used 242K times.

96% of users use companions only as statics while the rest 4% use them for other purposes. Among these for some of them should be rather implemented as regular nested objects (such as loggers, plugin implementations) while some should be available as companions (such as static factories implementation or delegation, static interfaces imitation).

Offtopic comment

Theoretically, companion objects can be used to create true static interfaces using something like this:

interface RingHolder<Self> {
    abstract companion object : Ring<Self>
}

interface Ring<T> {
    fun sum(a: T, b: T): T
    ...
}

operator fun <T: RingHolder<T>> T.plus(other: T): T =
    T::companion.sum(this, other)

...

value class IntWrapper(val value: Int): RingHolder<IntWrapper> {
    override companion object : Ring<IntWrapper> {
        override fun sum(a: IntWrapper, b: IntWrapper): IntWrapper =
            IntWrapper(a.value + b.value)
        ...
    }
}

Problems

Despite the huge functionality the feature gives, it causes several problems.

Scope breakage

The concept of scope is widely used among programming languages and Kotlin especially.

class A {
    private val a = 0
    // a is available here
    // b, c and d are not avalable here

    fun g() {
        val b = 1
        // a and b are available here
        // c and d are not avalable here

        fun f(c: Int) {
            // a, b and c are available here
            // d is not avalable here
            if (c == 0) {
                val d = 3
                // All a, b, c and d are available here
            }
            // a, b and c are available here
            // d is not avalable here
            run {
                val d = 3
                // All a, b, c and d are available here
            }
            // a, b and c are available here
            // d is not avalable here
        }
    }
}

companion object work the opposite way:

class A {
    private val a = 0
    // All a, b and c are available here

    companion object {
        private val b = 1
        val c = 2
        // b and c are available here
        // a is also available but only on instances of `A`.
    }
}

One may say that companion object work exactly as non-inner nested object, but that's also false: in case of class Nested b is not leaked to the outer scope:

class A {
    private val a = 0
    // a is available here
    // b and c are not avalable here
    // ↑

    object Nested {
        private val b = 1
        val c = 2
        // b and c are available here
        // a is also available but only on instances of `A`
    }
}

With modifier protected, companion objects are even more confusing:

open class A {
    companion object {
        @JvmStatic
        protected fun f() = Unit
    }
}

class B: A() {
    fun f() = A.f()
}

Here f is protected in object which effectively means that it is private in it as objects are neither open nor abstract. However, the code works because f is leaked to A. Without @JvmStatic the snippet is not compilable: Using protected members which are not @JvmStatic in the superclass companion is unsupported yet.

On the other hand some static/namespace/whatever modifier would fix this problem and not introduce any completely new concept because suspend or @Composable already work this way.

Inconvenient syntax

It is quite often that you want to place some instance-less member near its only usages to improve readability and reduce navigation among the codebase during reading. However, it is not possible if the companion object already exists: you cannot split it.

Furthermore, creating the companion object with its nested scope just for a single member is unnecessary verbose.

Java interopability

By default companion object members are not exposed to Java as static members. To make it work this way you can add @JvmStatic on a function.
This way interopability becomes even more verbose.

companion object {
    @JvmStatic
    fun create(...)
}

instead of

static fun create(...)

Reflection breakage

@JvmStatic breaks scopes in yet another way: using Java reflection.
@JvmStatic members are added to the outer scope even though they are defined not there which is misleading.

class Outer {
    companion object {
        @JvmStatic fun f() {}
    }
}

fun main() {
    println(Outer::class.java.methods.map { it.name })
}

[f]

Non-extensibility of Java classes

Java classes have no companion, so they are not extensible.

Slower class initialization

As companion object is yet another class, it requires additional initialization which affects large codebases if the member is not @JvmStatic.

Approaches to solve and their drawbacks

Combining with namespaces feature.

Code example:

class Outer {
    fun f() {}
    // member of namespace Outer being also a class
    namespace fun g() {}
}

// standalone namespace
namespace Std {
    fun f() {}
}

// namespace extension
fun Outer::namespace.h() = g()

Drawbacks

• Keyword namespace is misleading as it is not obvious that the function g itself is not namespace but belongs to a namespace, declared by the containing class. Compare it with suspend or static which declare that the marked member is suspend or static itself.
• Even if you understand the previous point, it is counter-intuitive why the regular members of class are not namespace ones, because they are also available within the lexical namespace/scope of the declaring class, but the namespace must be 'constructed' to make the name available. Compare Outer.g() and Outer().f(). That is also confusing.
• There are also complaints from the language evolution team about ability to combine the features.
• Binding namespaces to the class types would significantly limit applicability of the feature while not binding it would break class encapsulation, because there would be no way to create static factories which predictablely use private members of the class. package-private or even internal visibilities are not a solution as the main entity ensuring invariants in the language is class, it would be horrible to break this basic OOP concept.

Disclaimer

It does not mean that namespaces shouldn't be implemented but they should be discussed and implemented separately in a different KEEP.

Adding fake companion to Java classes

It would solve the problem of extensibility.

Drawbacks

• It would solve only one of six problems.
• There are possible collisions:

  public class A {
      public static class Companion {
  
      }
  }

Ability to specify @JvmStatic on the whole companion object

It would slightly simplify the declaration of all companion object members as conveniently interopable from Java and remove the necessity to initialize companion object.

Drawbacks

• It would solve only 1.5 of 6 problems.

Making all members @JvmStatic by default

It would slightly simplify the declaration of all companion object members as conveniently interopable from Java and remove the necessity to initialize companion object.

Also, it will naturally bring delegated factories to Java.

class A {
    companion object Factory: AbstractFactory<A>()
}

fun f() {
    val x: A = A.create(...)
}

void g() {
    A x = A.create(...); // not A.Factory.create(...);
}

Drawbacks

• It would solve 2 of 6 problems. By combining with the previous solution, 3. By allowing spliting companion declarations if they don't inherit anything and allowing using companion as modifier even 4.
• There can be clashes when companion property/method name is equal to one in the containing class. However, this can be gradually forbidden.

  class A {
      val a = 3
      companion object {
          val a = 4
      }
  }

• It will create many new functions which might be not desired because of the binary size.

Implementation of statics

Introducing static keyword, static extensions, etc.
It would allow to gradually solve the problem with scopes by iterative replacing deprecated @JvmStatic with keyword static and moving the declaration to the outer class.

Migration plan

Step 1.

• Introducing statics.
• private/protected companion members accessed from the outer scope become warnings. The quick-fix would suggest moving them with dependents to outer class with static modifier.

  class A {
      val a = c
      val b = d
      companion object {
          private val c = 4
          val d = c
      }
  }

  ↓

  class A {
      private static val c = 4
      val a = c
      val b = d
      companion object {
          val d = c
      }
  }

  • There is a corner-case: protected member in companion received from some super class of the companion. It is impossible to make it static directly by moving to the outer class body. The best way for the user is to refactor code because it is very confusing to call protected methods not being an ancestor of the base class (see the example in the somewhere above). Nevertheless, there is a workaround:

    open class Base {
        protected fun f() = 2
    }
    
    open class A {
        companion object : Base()
    }
    
    class B: A() {
        fun f() = A.f()
    }

    ↓

    open class A {
        private interface BaseImpl {
            fun g(): Unit
        }
        companion object : Base(), Unit {
            override fun g() = f()
        }
        static fun f() = Companion.g()
    }
    
    class B: A() {
        fun f() = A.f()
    }

• The quick-fix for conversion from companion object (and its methods/properties) to static methods/properties of the outer class is optional but still available for other (public/internal) methods as well, just it is not a warning for them.
• @JvmStatic becomes deprecated, the hot-fix is the same. But if the moved member is implemented by the object, the static version can just call the companion one.

Step 2.

• Convert warnings to errors.

As a result, companion objects will follow the regular nested object rules besides being potentially accessed with pure outer class name.

Side comment

I highly dislike suggested ::type scope specifier as type is expected to be class with type arguments but here it is not ::class with type arguments (which might also exist and become replacement of typeOf(...)). There should be a better alternative such as ::static:

class A {
    static fun f() {}
    fun Int::static f() {}
    static fun Int::static f() {}
}

fun Int::static f() {}

Drawbacks:

• There are multiple places where to declare a public/internal member if we don't care about interop.

  • companion object (still relevant but only for public/internal without interop now) member/extension
  • static member/extension
  • Inside namespaces when they become available.

  The resolution is easy. namespaces are not bound to types. If you don't want your declaration to be renamed on some type rename, you don't want it to access any the type privates, this is the option.

  • If your declarations form some independent entity like type-safe key etc., then use a companion.
  • Otherwise, use statics.
  • Choice between extensions and members is same to one for the regular functions.

Conclusion

Only the last option solves all the problems and the pre-last solves 2-4 of 6. I find the last one the best as it makes language mental model simpler and more straight-forward. The second my choice is the pre-last solution because even though it solves only some of the problems, no new language constructions are added.

[FilipDolnik]

I would also consider adding @JvmStatic/@PlatformStatic on a whole companion. It completely solves 1.b without bringing any new concepts. Annotation is fine here because it does not change the semantics of the language, only implementation details on the target platform. It probably could be used on regular objects as well.

I don't think this change would make a significant difference (though better than nothing). The vast majority of declarations in companion objects today could be annotated like that and would be if the authors of the given code cared enough about interoperability - just looking at the Github numbers, this is not the case.

From my experience, the people who would care about the interoperability and would be willing to do the extra work required, cannot add such an annotation afterwards, usually because they do not own the Kotlin part of the codebase. I'm talking about general Kotlin libraries, but also in KMP projects with split repositories - usually, the iOS team cannot directly contribute to the Kotlin codebase easily in that situation.

The only way to solve this interoperability issue is to have a syntax that is simpler/shorter than the alternative, so that the authors are motivated to use it. Having the same syntax as the alternative + extra annotation, which is there only for interoperability, simply doesn't cut it.

As mentioned, the vast majority of the declarations in question could be exposed in a platform-compatible way by default. Given that Kotlin has a high emphasis on interoperability, it feels right for it to be the default. It also feels right for the default to be less verbose, not more. (note that just changing the compiler behavior for companion objects isn't feasible due to backwards compatibility)

2.a is much more controversial because it brings static concept back in Kotlin and it is something that most of commenters here would like to avoid.

I just want to point out that there is a strong bias in the conversations in this KEEP because significant number of people who would care a lot about the interoperability aspect of this feature (which the annotations don't help much with) don't even know that something like KEEP even exists because they are not just (or even at all) Kotlin developers, but work in other languages (Java, Swift) with Kotlin.

[SPC-code]

@FilipDolnik I am not sure if situation with codebase you don't own could be affected at all. At maximum one could provide IDE inspection or compiler warning. And it could be done with ANY proposal. For example, you can analyze companion and suggest marking it with @JvmStatic exactly the same way you suggest migrating to any other feature. You can even add a compiler flag that would treat any companion without inheritance as JvmStatic.

[frozenice]

a) static keyword that simplifies declaration of behaviors compiled to platform statics.
b) ::type/::whatever to extend the namespace.
I do not see any connection between those two (please explain it if there is).

In my view: If x) are instance methods and y) are extension methods, then b) is the analogue to y) - just for the static scope, instead of the instance scope. b) provides the functionality for Kotlin's extensions concept, with the usual limitations such as no access to a)'s private members (but access to privates in the scope it's declared in). [I don't see it as a standalone thing, hence my comments that the namespace feature should be discussed separately.]

[FilipDolnik]

I am not sure if situation with codebase you don't own could be affected at all.

Well, of course it can. An IDE inspection can be one thing, but to be honest, having an IDE inspection telling you to add more boilerplate because it's recommended for whatever reason feels a bit like going back to Java.

Although I wasn't necessarily talking about existing code - any change to the language will take a long time to propagate. My point was primarily about new code.

For example, I currently never write something like this:

class A {
    companion object {
        private const val foo = 0 // foo being a constant used from methods of A
    }
}

instead I do this if possible:

class A {
    private val foo = 0
}

That's because the "better" option is just so much more verbose for little gain. However, I can see myself write the following if such syntax was available:

class A {
    private const val foo = 0 // or even `private static const val foo = 0`
}

Similarly, my claim is that if Kotlin has something like:

class A {
    static fun foo() ...
}

that this syntax will be what most people will use as the default, instead of the companion objects:

class A {
    companion object {
        fun foo() ...
    }
}

Therefore, the improvement to interoperability with other languages is just a side effect of using a better syntax, the developers don't even have to know about it being better for interoperability as well. On the other hand, they have to think about it all the time with the current annotations.

[zhelenskiy]

@SPC-code

"scope breakage" is a thing we live with for years and it does not bother people.

I wouldn't agree with that statement. It bothers a lot and I gave examples how. Furthermore, you tend to explain things in terms of mental models and teaching students. So, do you say that protected members can be accessed within ancestors of their types? However, if the ancestor is a companion object, then it can be used within the ancestor of the companion object owner as well, and if that is inherited by another companion object itself, then so on.

However, here f is an unresolved reference for some reason being still available inside B.companion.

open class A {
    companion object {
        @JvmStatic
        protected fun f() = Unit
    }
}

class B {
    companion object: A()
    fun g() = B.f()
}

The fact that we have the problem for years also does not mean we should not try to solve it. Otherwise, should we also close compiler bugs with the description "Too old issue"?

So, you either make it "a feature instead of bug" or you create two features with different bugs existing simultaneously.

I don't understand the point. Why do new features have to have bugs [in design]?

Furthermore, companion objects will never be removed, so the problem could not be solved at all.

I didn't suggest to remove companion objects at all, just to limit them and provide a better solution for the cases where they don't work anymore, especially as it solves all the problems and simplifies the language mental model.

Splitting companion blocks also could be considered a bad thing, not a good thing. it decreases the readability, so it should be discussed separately.

I would say it improves the readability because of the reason I already mentioned: you don't need to scroll within the file to find the only usage. You can place the member just nearby. The same thing is about public/private blocks for me. We use documentation to see the API in a nice view while if I need to see implementation, I would prefer to have everything in the same place:

fun f() = fImpl()
private fun fImpl() = ...

fun g() = ...
fun h() = ...
...

But not:

fun f() = fImpl()
fun g() = ...
fun h() = ...
...
private fun fImpl() = ...

Other things also work more or less right now. All in all, there are two severe problems that are not solved right now.

So, for me all the issues persist.

The proposed solution is not a single feature, but two mostly unconnected features:
a) static keyword that simplifies declaration of behaviors compiled to platform statics.
b) ::type/::whatever to extend the namespace.
I do not see any connection between those two (please explain it if there is).

I'd say 2b depends on 2a, so 2a should be discussed first.

I prefer statics here as they solve all the problems, including those you prefer to ignore for some reason.

2.a is much more controversial because it brings static concept back in Kotlin and it is something that most of commenters here would like to avoid.

I see, but I don't see another solution that solves all the problems.

Also, it blocks the whole branch of language development because nobody will create a new feature that already partially exists with completely different explanation.

I don't see how it blocks anything.

Now my question to you. Is there a problem in the first part of your analysis (you should probably number them for convenience) that is not covered by solution 2.b?

None of the problems besides the one with extension will be solved.

Just for the record, in my personal opinion that the combination of "companion extensions" and object level annotation cover all bases perfectly and does not require adding a controversial feature.

In my opinion, they don't cover static factories which are highly used and cannot be implemented without the access to the class privates. Furthermore, this does not solve existing issues I mentioned in the analysis.

What is the most important it leaves space for further talk about namespaces in future.

I don't see how statics block namespaces.

[serras]

Summarizing a bit what we seem to agree on this discussion up to now (18 June 2025):

• The Class::static syntax seems unavoidable to implement some sort of extension on the static scope, and it seems this is the most direct route to that goal.
• The syntax between "static members" and "type extensions" should be aligned; using static for one and ::type for another doesn't seem to convince anybody, since all the proposals always use the same term.
• Regardless of the outcome of this KEEP, it seems desirable for Kotlin to have a (maybe separate) local packages or namespace feature.

[SgtSilvio]

Apart from ::type, the suffix ::class was also considered. In fact, this syntax is slightly better in that you are cannot use just any type when declaring a type extension (List<Int>::type is not allowed). However, it would lead to a scenario in which Int::class have completely different meanings in a signature and in a body.

fun Int::class.zero() {  // type extension over 'Int'
  val k = Int::class     // k has type 'KClass<Int>'
}

This argument applies to any <suffix> name (class, type, static, namespace) when using the syntax
fun Class::<suffix>.classExtensionFunction().

Example when a class defines a type function:

class Foo {
    fun type() {}
}

fun Foo::type.zero() {  // type extension over 'Foo'
  val k = Foo::type     // k has type 'KFunction1<Foo, Unit>'
}

Example when a class defines a type property:

class Bar(val type: String)

fun Bar::type.zero() {  // type extension over 'Bar'
  val k = Bar::type     // k has type 'KProperty<String>'
}

You can exchange type with static, namespace, ... and you always get different meanings whether used in the signature or elsewhere.

Actually, I would argue that using class as the suffix is the best of these options. It is already a reserved keyword and therefore won't clash with user defined code. Also, ::class imho makes sense semantically and I guess might need less explanation as no new terminology needs to be defined.

Instead of arguing about the suffix name, it may be better to use a different type/class extension function syntax anyway.
For example, has the syntax fun Class::classExtensionFunction() already been considered?

[SgtSilvio]

Note here that we have here 9 choices, as each of the dispatch and extension receiver could be (1) missing, (2) instance, (3) static.

Listing all these 9 different forms of functions in one place maybe helps in discussions.
The following shows what is currently proposed in the KEEP (please correct if wrong):

class Foo

fun function() {}
fun Foo.instanceExtensionFunction() {}
fun Foo::type.classExtensionFunction() {}

class Bar {
    fun instanceFunction() {}
    fun Foo.instanceExtensionInstanceFunction() {}
    fun Foo::type.classExtensionInstanceFunction() {}
    static fun classFunction() {}
    static fun Foo.instanceExtensionClassFunction() {}
    static fun Foo::type.classExtensionClassFunction() {}
}

Using the syntax for type/class extension functions that I proposed above (removing the need for type/static/... suffixes), the functions would look like the following:

fun function() {}
fun Foo.instanceExtensionFunction() {}
fun Foo::classExtensionFunction() {}

class Bar {
    fun instanceFunction() {}
    fun Foo.instanceExtensionInstanceFunction() {}
    fun Foo::classExtensionInstanceFunction() {}
    static fun classFunction() {}
    static fun Foo.instanceExtensionClassFunction() {}
    static fun Foo::classExtensionClassFunction() {}
}

[SgtSilvio]

Using Class::type would only make sense to me when it could be used in other contexts as well. This syntax creates a feeling that it could be used somewhere else. It seems intuitive to think about Class::type as a namespace. As a general namespace concept is out of scope/not the goal here, the Class::type syntax (including all replacements of type with static, namespace, ...) maybe also should be avoided.

There's also an additional problem of nesting here. People around here may like the nesting of companion objects, but it is unclear why we need to nest something which is in no way nested to an instance or a class. My personal opinion is that static members live on a parallel scope to instance members, and thus should be declared also in "parellel nesting".

This statement supports my above argument. Imho, Class.extensionFunction vs Class::type.extensionFunction creates a notion of nesting; it feels like there is a nested scope called type inside the Class.
Using . and :: would each address one of the two parallel scopes of the same class. (Similar to other naming discussions, :: could be replaced by different syntax, so I would like to have a discussion about this idea without directly starting a discussion about exactly which symbols should be used.)