Context-sensitive resolution

[serras]

This is an issue to discuss context-sensitive resolution. The current full text of the proposal can be found here.

We propose an improvement of the name resolution rules of Kotlin based on the expected type of the expression. The goal is to decrease the amount of qualifications when the type of the expression is known.

[serras]

⚠️ The proposal mentions some non-goals for the KEEP, in particular relating to improving resolution in calls. Please read that section carefully.

[FilipDolnik]

Hi!

First of all, I want to say that I really like this idea, and I've been missing this feature in Kotlin for a while.

I have one question/comment about the decision not to use the Swift syntax .value (or something similar).

I use both Kotlin and Swift, with Kotlin as my primary language. I personally strongly prefer the .value syntax because it makes it easier to understand exactly where the value comes from. On the other hand, I tend to avoid using the workaround with static imports in Kotlin, which can be used to simulate this feature (without the .), because I've run into too many situations when it creates confusion. (As the document mentions, developers ignore the import section.)

To be fair, this is partially because I only use the PascalCase naming convention for enum cases (which works better with the naming convention of sealed classes). Therefore, it's easy to create name collisions with another class or, worse, an object.

The document mentions two issues why this wasn't the chosen solution:

The big drawback of this choice is that new syntax ambiguities may arise, and these are very difficult to predict upfront. Code that compiled perfectly may now have an ambiguous reading by the compiler.

Furthermore, Kotliners already use a pattern to avoid re-writing the name of an enumeration over and over, namely importing all the enumeration entries, which makes them available without any . at the front. It seems better to support the style that the community already uses than trying to make people change their habits.

Let's start with the second one. The issue here is that there is currently no other way to do it, so just because people use it doesn't necessarily mean it's the better option or that they wouldn't want to switch to the new syntax (also, the old syntax doesn't go away).

As for the first issue, I can't think of any situation where this new syntax would create a problem because I don't think Kotlin has any expression and type declaration that can start with a .. However, I understand that this is difficult to prove and predict. But I think this is solvable by having a longer beta cycle and the usual optional compiler flag + warnings, then enabling the flag by default, as is the case for other features.

It wouldn't make sense to bother with the issues mentioned above if there weren't any advantages to compensate for them. However, I think this dot syntax has significant benefits, or to put it better; the currently proposed syntax has some significant drawbacks.

First of all, clarity. The . syntax makes it immediately obvious what the expression is. Compared to the proposed syntax, in which case it can be basically anything from anywhere (like an object, class, etc.), and you have to rely on the IDE (or manually looking at the imports) to recognize that. (my main issue with the static imports)

Second: With ., it's possible to use this feature even in a scope that contains this name conflict (with the proposed syntax, you have to use the whole name or resolve the name collision).

Third: Having the . syntax should make it less likely that we will run into some unsolvable issue when this feature is extended to cover all the other use cases (like, for example, the overloading resolution).

Last but not least, the proposed syntax allows for creating nasty semantic bugs that the compiler cannot always catch. For example, given this code:

sealed interface I {  
      
    object SomeClass : I
      
    interface SomeInterface : I
}

import some.package.*

fun foo(i: I) = when (i) {  
    SomeClass -> println("some case")  
    else -> println("default")  
}

Now add this object:

package some.package

object SomeClass : I.SomeInterface

The result is a change in the semantics of the foo function due to a name collision.

Yeah, this is a convoluted example, and in most cases, the result will be a compilation error (still not good, but better). However, I wouldn't be surprised if there were more realistic examples.

I also don't like that this feature's behavior depends on the imports. So many times, I have experienced that the indices in IDEA get corrupted, and the IDE removes some "unnecessary" imports. I somehow have a feeling that this feature could be especially prone to this problem. The result would again be a potentially silent change to the program's behavior in the worst case.

Note that this issue will occur more frequently if the project uses the camelCase naming convention for things like enum cases. I know that this is not in line with the official code style, but it will be the default used by Swift developers who use Kotlin as their secondary language and expect this feature not to have this problem.

[serras]

As for the first issue, I can't think of any situation where this new syntax would create a problem because I don't think Kotlin has any expression and type declaration that can start with a ..

The problem arises when you combine .value with infix functions. Right now the following expression:

thing
  .foo

is not ambiguous: access member foo on receiver thing. However, once we bring .foo as a potential expression into the mix, we would need some heuristic to decide whether we should parse it as an infix function applied to .foo or at the access member.

Second: With ., it's possible to use this feature even in a scope that contains this name conflict

I don't 100% follow here. The current proposal allows for situations like the following, where the resolution of ON depends on the type of Status.

enum class Status { ON, OFF }
enum class Switch { ON, OFF }

fun f(s: Status) = when(s) {
  ON -> ...
  OFF -> ...
}

[daniel-rusu]

I like how this KEEP reduces clutter and improves readability for most scenarios.

Note that value equalities (==, !=) are not part of that group, since they are always resolved to kotlin.Any.equals

Inline value classes have a special equals operator function that isn't overriding Any.equals (behind a feature flag). Similarly to the Color example from the KEEP, will constants from the companion object of an inline value class benefit from this feature?

Some concerns:

1. Bringing constants or enums into the scope seems natural. However, bringing functions is quite surprising.
2. Since this has the lowest precedence, I'm really concerned that introducing new unrelated code can auto-magically change the behavior of existing code without even realizing it. For example, if someone creates a function with the same signature, my existing code automatically binds to that new function. This is especially likely in large projects where others can define public top-level functions (or constants of the same type) in a completely different part of the codebase (which is common with junior developers) and then the behavior accidentally changes.
3. Although the lowest-precedence rule is there to resolve ambiguities, it seems counter-intuitive to existing precedence rules. For example, when having similar-looking code by using a lambda with receiver (eg. the with function), function calls on the receiver take precedence over top-level functions with the same signature. However, the opposite is true with the lowest-precedence rule which is surprising.

Reversing the precedence order would address concerns 2 & 3 but I'm not sure if that introduces other problems.

Alternatively, I think that using the .VALUE or .function() syntax would address all these concerns as it makes it obvious where the function or value is coming from and avoids accidentally changing the binding as the syntax signifies that it's coming from the current scope. I think that using this new feature alongside infix functions should be much less common, so using heuristics to resolve that scenario along with the .VALUE syntax seems like a much safer approach (perhaps lower precedence after current compiler rules).

[gildor]

I think .value syntax is disregarded too soon, it would be great to add a section about it just to discuss potential advantages of it. Like already mentioned above and the fact that it can be easier to use for other important cases like function call with expected type switch(.ON)

One more advantage of .value is very clear for IDE, I understand that it may be improved for proposed syntax to prioritize expected type, but .<caret><TAB> makes it very clear and get only relevant suggestions for auto complete

Having it explicit is actually looks pretty good to me and .value syntax looks pretty natural for this use case and already well-tested in Swift and I don't see it as an issue for Kotlin developers, rather opposite, when existing importa approach is mixed with proposed expected type

[FilipDolnik]

As for the first issue, I can't think of any situation where this new syntax would create a problem because I don't think Kotlin has any expression and type declaration that can start with a ..

The problem arises when you combine .value with infix functions. Right now the following expression:

thing
  .foo

is not ambiguous: access member foo on receiver thing. However, once we bring .foo as a potential expression into the mix, we would need some heuristic to decide whether we should parse it as an infix function applied to .foo or at the access member.

Oh, I see. So the issue is that there can be a infix fun SomeType.foo(a: Int) in SomeEnum.

I think that the use of infix function calls in this way should be prohibited. I'm not convinced that such a pattern should exist because it is confusing even for the developer, not just the parser.

I also do not think that it would be used that often. Infix functions are generally used relatively rarely outside of DSLs, and in DSLs, it's common to achieve similar syntax (without the dot) by using contexts. Regular code can also do the same using the static imports.

Alternatively, we can give priority to the other scopes - just like the proposal does for the name collisions. This kind of collision will be much rarer, but it would complicate the parsing, and I'm not sure it's worth it.

Second: With ., it's possible to use this feature even in a scope that contains this name conflict

I don't 100% follow here. The current proposal allows for situations like the following, where the resolution of ON depends on the type of Status.

enum class Status { ON, OFF }
enum class Switch { ON, OFF }

fun f(s: Status) = when(s) {
  ON -> ...
  OFF -> ...
}

The issue I mentioned is about a situation in which you already have the case "ON" in scope. In that case it would always take precedence even though it's not the correct type (assuming I understand the KEEP correctly).

For example, following is not possible:

sealed interface Json {

  class String : Json

  class List : Json
}


fun f(json: Json) = when (json) {
  is String -> ...
  is List -> ...
}

(However, it would be possible with the . syntax.)
This is also a good example of the last issue I mentioned:

fun f(json: Json) = when (json) {
  is Json.String -> ...
  is List -> ...
}

This code would work just fine until you import List in the file.

[CLOVIS-AI]

Hi!

I really like this proposal, I don't have much to say about it.

I'm 50/50 on member functions being included. The main use-case I see for including member functions is when building complex objects:

AComplexObject(
    ANestedComplexObject(
        …
    )
)

but since the current conventions are to create constructors/factories as top-level entities, and this KEEP explicitly excludes argument resolution, this isn't a very compelling use-case. I wonder if excluding member functions would be more confusing for beginners ("why does it work for some things and not for others") than including them.

One potential risk of this proposal is the difficulty of understanding when exactly it is OK to drop the qualifier, which essentially corresponds to understanding the propagation of the expected type through the compiler.

I think this is mostly mitigated by the fact that IntelliJ will always let you write the name of the enum element, auto-complete, and will add the qualified type automatically if necessary (which is the current behavior).

---

Now, on the .VALUE syntax discussion.

Currently, there are two main ways enums are used:

• With explicit naming (Foo.Bar),
• With star-import (Bar).

If we are in a codebase that uses star-import (and many of them do), the arrival of this language feature with .VALUE syntax would mean:

• Replacing all usages of Bar by .Bar
• Removing all star-imports

To me, this is clearly a regression. If a codebase has to be made more verbose to accommodate a new language feature made to simplify this exact use-case, then I believe it is a failure of the language feature.

Before:

import TransferType.*

when (transfer) {
    Entry -> …
    InternalTransfer -> …
    Exit -> …
}

After:

when (transfer) {
    .Entry -> …
    .InternalTransfer -> …
    .Exit -> …
}

Why add syntax when the original code worked already?

I much prefer avoiding adding any new syntax at all, and simply codifying the existing pattern and conventions into the compiler.

Without the .VALUE syntax, migrating code looks like:

• The star-import is now flagged as unused by the IDE.

That's it. Before:

import TransferType.*

when (transfer) {
    Entry -> …
    InternalTransfer -> …
    Exit -> …
}

After:

when (transfer) {
    Entry -> …
    InternalTransfer -> …
    Exit -> …
}

Adding new syntax means having to teach users about the new syntax. Sure, the .VALUE syntax is easy to explain, but it also doesn't provide enough value to require taking time from a beginner. Allowing the compiler to make the existing code patterns safer and less verbose with no user intervention seems to me like a much better choice.

So, I'm in favor of keeping the KEEP as-is: purely about resolution, with no new syntax at all.

[FilipDolnik]

If we are in a codebase that uses star-import (and many of them do), the arrival of this language feature with .VALUE syntax would mean:

• Replacing all usages of Bar by .Bar
• Removing all star-imports

The static imports do not go away, so existing code doesn't have to be migrated at all, even with the .value syntax.

Why add syntax when the original code worked already?

I'm not convinced that it does, at least not universally. The static imports create name collisions. The syntax without the dot has the same issue, potentially much worse than the static imports.

Depending on the kind of code you write they can be very common. For example when you write mapping between DTOs and domain objects - they tend to use the same names for nested types.

To me, this is clearly a regression. If a codebase has to be made more verbose to accommodate a new language feature made to simplify this exact use-case, then I believe it is a failure of the language feature.

I think readability is more important than reducing verbosity (especially when we talk about an extra dot). I consider the .value syntax to be much easier to understand, and it doesn't have the issues with name collisions. Also, as was mentioned above, it works better with code completion in the IDE, so that's already a significant improvement over the static imports (and the proposed syntax).

[gildor]

Without the .VALUE syntax, migrating code looks like:
The star-import is now flagged as unused by the IDE.

I'm not sure that it's true, considering that the expected type resolution has the lowest priority, so at least from compiler point of view, import is used
Of course IDE could be smart enough to detect it, but still

doesn't provide enough value to require taking time from a beginner

Beginners will follow what IDE would suggest, now it's a non-static version, if it would change to .value, they will use it instead, I think it's very easy to understand
And the value comes not from saving one dot, or the potential learning curve for beginners (which is questionable IMO), but from readability and making it explicit, also to support more complex use cases like function invocation with expected type, methods (I would much prefer for example Button(.width(10.dp)) instead of implicit Button(width(10.dp)) or current Button(Modifier.width(10.dp)), especially when I have multiple params Button(.width(10.dp), .BLUE, stringResource(.string.OK))

[CLOVIS-AI]

I guess this is going to be an issue of taste, but I don't think

Button(.width(10.dp), .BLUE, stringResource(.string.OK))

looks like Kotlin, whereas this KEEP aims towards:

Button(width(10.dp), BLUE, stringResource(string.OK))

I don't think this KEEP (which is about type resolution, which is almost a detail to most users) should be the start of such a major syntactical change to the language. And anyway, this KEEP explicitly excludes function calls.

[serras]

Let me try to spell out some of the concerns and how important they were in the current design.

☣️ Full backward compatibility: every program which currently compiles should keep compiling with the same behavior and no additional warnings.

• Just to clarify, we do not expect people to change existing code when this feature is enabled. So there's no need to "migrate", in the strongest sense of the word; you can of course reduce some imports by taking this into account.
• Note that even though we may want to guide users into a certain pattern, we cannot just decide "people should not write code this way", and break some existing codebase.

🛑 Toolability: it should not become way more difficult to provide tooling for this feature.

⚠️ Forward compatibility: if a program compiles with this flag on, it should be more or less resilient to changes.

• It should suffer from the same problems as the rest of Kotlin code. For example, right now you can change resolution if you introduce a function in a class which hides an imported extension function, since the former has more priority than the latter.

⚠️ User expectations: the feature should not guide users into wrong expectations, as far as possible.

---

About .value syntax:

• Backward compatibility
  • This variant introduces new syntax for type-guided resolution, so once we've parsed the file, there's no overlap with any other resolution, so we ensure backward compatibility.
  • Alas, it's not clear that we can actually parse files in a fully backward compatible way if we introduce that syntax. The reason is that foo<newline>.bar is now unambiguously a field access, but it may be get another interpretation with .value syntax. Note that using <newline>. is very common in Kotlin code.
  • As a result, any variation using this syntax should have a good answer to the question "how to parse things unambiguously?"
• Toolability: one possibility would be to make the parsing dependent on some compiler flag. However, that means that now parsing the file depends on some external input (Gradle file), so tools need to be updated to consult this (which is not always trivial).
  • You can see that other KEEPs extend syntax in a backward compatible way, so we can update the parser to the larger language, and then emit a warning if a new feature is being used.
• Forward compatibility: again, .value syntax is the most explicit, so the chances of changing resolution are lower.
  • And since all type-guided resolution is at the same level, we would get at most an ambiguity error, not a resolution change.
• User expectations: one very important difference with Swift is that we take a restrictive route, in which we are very clear about when you can expect types to guide resolution. Swift, on the other hand, allows .value syntax everywhere, and tries its best to decide which is the correct way to resolve it.
  • I'm afraid people would expect .value to work everywhere, instead of the handful of cases in this KEEP.

About having the last priority:

• Backward compatibility: this is the main motivation. Any other choice would potentially break existing code.
• Forward compatibility: it's indeed the case that if you introduce another import (as done with Json.String above), your resolution may change. Note again that this is not the only place in Kotlin where this can happen.
  • We expect the IDE and tooling to help here. If suddenly a type resolves differently in a when condition, you'll get a message about "this condition is always false" in most cases (since you're pattern matching on a value of a particular type and then checking the type from a completely different hierarchy).

[gildor]

@CLOVIS-AI problem comes when different params use expected type, and some just regular function calls.

Yes, this proposal doesn't support method invocation of expected type, but it's a very powerful feature; I see that it may save more code than in the case of when/enums, and the decision now will affect how it is implemented in the future, and even if it possible to implement.

I would say that I'm not against the proposal; I just would like the KEEP to have a comparison for .value syntax (advantages and disadvantages) because I still see serious advantages, mostly because it's very explicit and concise.

[serras]

Bringing constants or enums into the scope seems natural. However, bringing functions is quite surprising.

Note that there's a fine line into what counts as function here and what not. The main issue is that a constant may not have an explicit functional type, but there may still be an .invoke operator defined on it.

[FilipDolnik]

User expectations: one very important difference with Swift is that we take a restrictive route, in which we are very clear about when you can expect types to guide resolution. Swift, on the other hand, allows .value syntax everywhere, and tries its best to decide which is the correct way to resolve it.
I'm afraid people would expect .value to work everywhere, instead of the handful of cases in this KEEP.

Sure, but the code wouldn't compile, so people would quickly learn about this difference. Also, I thought this might be only a temporary limitation that might change with some future KEEP. Therefore, it makes sense to consider what that future would look like, and I feel the current syntax will be very limiting. (For example, for the Modifier builder mentioned above.)

Alas, it's not clear that we can actually parse files in a fully backward compatible way if we introduce that syntax. The reason is that foo<newline>.bar is now unambiguously a field access, but it may be get another interpretation with .value syntax. Note that using <newline>. is very common in Kotlin code.
As a result, any variation using this syntax should have a good answer to the question "how to parse things unambiguously?"

Swift also supports the foo<newline>.bar syntax, so they had to solve the same issue. I'm not sure, but I think that Swift always gives precedence to a member call, even if such a member doesn't exist. I believe that this approach makes sense for Kotlin as well, and it would be fully backward compatible.

It's true that this would be slightly more restrictive and more or less prevent the usage of this feature in implicit returns in multi-line lambdas. However, I'd question how frequent this pattern would be in practice.

It should suffer from the same problems as the rest of Kotlin code. For example, right now you can change resolution if you introduce a function in a class which hides an imported extension function, since the former has more priority than the latter.

Yes, the issue with forward compatibility already exists, but I think it makes sense to consider not contributing more to this problem if there are alternatives.

We expect the IDE and tooling to help here. If suddenly a type resolves differently in a when condition, you'll get a message about "this condition is always false" in most cases (since you're pattern matching on a value of a particular type and then checking the type from a completely different hierarchy).

I agree that you will usually (but not always) notice the issue because of a compilation error or at least a warning. However, my main problem is that if such a collision happens, you cannot use this feature without the .value syntax (whereas with the .value syntax, there is no ambiguity).

You also need to go and fix your code, which can become annoying depending on how often you run into the issue - which I think can be more frequent than expected, especially if this feature is used with functions and properties rather than just the enum cases and classes.