Explicit Type Parameters

[InversionSpaces]

This is a discussion of explicit type parameters KEEP.
The proposal introduces explicit type parameters for Kotlin functions.
Type arguments have to be passed explicitly for such type parameters on all call-sites:

inline fun <explicit reified T> List<*>.castAll(): List<T>

val list: List<CharSequence> = listOf("a", "b", "c")
val ok = list.castAll<String>() // ok
val error: List<String> = list.castAll() // error: type argument required

[SPC-code]

I like the idea in general, but I do not like yet another keyword. In my mental model there are two different kinds of "modifiers":

1. Those, that change the behavior of the code. Soft keywords are OK for that.
2. Those, that do not change behavior much but instead help the developer to provide more information to the compiler and optimize the compilation or provide additional safety. It could be done with annotations.

The key difference is that every programmer is expected to know all keywords, but not all annotations. They have different level of requirements. Of course, there are bad examples of annotations like @Composable (it should be a keyword). And there is a strong abuse of annotations in Spring and Android. But it does not mean that annotations do not have their use.

So, I suggest using annotation for this instead.

[lppedd]

I get what you mean, but not yet another annotation please : (
I'd say we should pick a keyword the can be used for other similar scenarios in the future.

[InversionSpaces]

I am a little bit confused, because for me explicit falls into your first modifiers category:

• It changes user facing behavior of the code, prohibiting some patterns of usage.
• It actually does not provide much information to the compiler and does not affect code generation.

For me, explicit is similar in this regard to the crossinline modifier.

Commenting on this:

every programmer is expected to know all keywords

I very much agree with the @IRus comment below: you need to learn about explicit only when there is an actual need to apply it for your code. One does not even have to know about the modifier to use APIs designed with it, because IDE will provide you with a clear explanation that type argument is required (in contrast with current "can not infer" generated by @NoInfer).

[SPC-code]

crossinline is actually a bad case. I skip it in my courses because it takes to much time to explain and is pretty useless to application developers. I would agree with you is we had some kind of language layers and separation of modifiers between those layers. But now people are expected to know and understand all modifiers.

[CLOVIS-AI]

I'm in favor of a keyword in this case because:

1. it will be very niche and very few developers will actually need to write it
2. if you read code that uses it, I think it's immediately obvious what it does

My personal rule for keyword/annotation is:

• Does it directly affect other Kotlin code? → keyword
• Otherwise → annotation (@JvmName, @JvmInline, etc). These may still create restrictions on Kotlin code (e.g. overload ambiguity).

Also, there are quite a few type-inference-related annotations in kotlin.internal, and I do think they deserve their own keywords.

But I agree that we're going in a direction where the average developer will not know all keywords. As long as they're soft keywords, I think that's ok.

[CLOVIS-AI]

Said otherwise, this feature is very similar to the proposed named keyword for mandatory named arguments. It's basically the same but for type arguments. They should either be both annotations or both be keywords.

[gpopides]

I also like the idea but i would agree that introducing new modifiers and keywords can increase the complexity for both people that already are using the language and new learners.

I'm not sure but is it possible to achieve this with contracts?

If doing this with contracts is not possible then i agree that using an annotation for this is more appropriate since the frequency of it is not that high

Also a note, in the document you mention:

However, in some cases, types directly affect the runtime behavior, and thus they are an important part of the source code. In such situations, inferring types is rather undesirable. For example, it would be strange to infer type argument of as:

I believe its safe to say that a big percentage of users is not aware when the type would affect the runtime behaviour. Will the compiler/ide give hints about this? Or how can we "force" defining a type as explicit?

[IRus]

On complexity in general: every feature adds some, so the useful question is who pays, how often, and whether the cost is local. Here the cost is on the API author, and the call site didn't change at all. It's also learn-on-demand – you never need to know the modifier exists until you write a declaration that needs it, and it doesn't change the meaning of any code you already know how to read. Worth noting that the concept isn't new either. @kotlin.internal.NoInfer already exists and users already encounter its behaviour through filterIsInstance and similar functions.

[gpopides]

Exactly, this feature is more focused to the stdlib and libraries in general. That's why i say that an annotation is more appropriate here instead of a new keyword.

For me a keyword is part of the language that you have to be aware of while an annotation is something that is there but most people pass over it without worrying about it too much.

In my opinion this feels similar with the DslMarker annotation where it is used mostly by library authors but application code just ignores it

[InversionSpaces]

I'm not sure but is it possible to achieve this with contracts?

It is theoretically possible do achieve with contracts, but contracts are about exposing invariants of the function implementation to the caller. This feature is rather about calling convention of the function, exposing it through contracts would also be more complex design and implementation wise.

I believe its safe to say that a big percentage of users is not aware when the type would affect the runtime behavior. Will the compiler/ide give hints about this? Or how can we "force" defining a type as explicit?

Well, I would argue that library authors should be generally more or less aware that their code depends on actual type argument, because it is usually correlated to using advanced features like reified type parameters or reflection.

The KEEP discusses "deducing" type parameter explicitness. In short, we believe it is still a design choice of the author, it is hard to guess the right thing from the information available to IDE or the compiler.