i do not even know where this path comes from

Is there a specific reason why Kotlin chose to use a randomly generated

Enum.hashCode()

?

I'd like to have a generic enum backed by `IntBuffer`s, which may lie perfectly fine in the enum companion object (and being so large as the enum values array) How may I create extension function of a generic enum which can somehow refer to that

IntBuffer

in the corresponding companion object?

for example

enum class Buffer { VERTEX, ELEMENT; companion object { val names: IntBuffer } }
inline fun <E> Enum<E>.bind(..) {
   // do something on names
}

I also kind of thought to sealed classes, problem is: they also require tons of boilerplate code. And boilerplate code for boilerplate code, I'd prefer code generation in this case

but I seemed to have some with only one digit for milliseconds

so it was failing with SSS

and I couldn't get it to work with S[SS]

Not really a Kotlin question but SO provides

val formatter = DateTimeFormatterBuilder()
    .appendPattern("yyyy-MM-dd'T'HH:mm:ss")
    .appendFraction(ChronoField.MILLI_OF_SECOND, 1, 3, true) // min 1, max 3 digits
    .toFormatter()
val formatDateTime = LocalDateTime.parse(value, formatter)

I think it’s:

fun <B> test(): B where A: B

You can add more sophisticated constraints in a

where

clause than you can in the parameter declaration itself

I already tried that. But that has an error like below.

A does not refere to a type paramter of test

I got it to compile by removing the

out

variance from <A>

Which I don’t understand…

🤔

@Robert Jaros said the correct answer.

fun <B, A : B> test(): B

That declares a new type parameter called A, which shadows the A declared on the class declaration

You can see that in IntelliJ: the

A

in

A: B

is coloured as an unused declaration. And if you rename it, the type parameter on the class is not also renamed.

So that is equivalent of

fun <B> test(): B

, but you’ll probably get type inference errors at call points.

So you mean,

fun <B, A : B> test(): B

is still correct answer, right?

No, it’s wrong because the A in the function declaration means something different to the A in your Scala code

It introduces a new type parameter, and does not bind B to be a supertype of the A parameter of the class declaration

True, my solution is wrong

But Kotlin seems to consider a subtype constraint on type parameters of a method to imply an

in

variance constraint on those type parameters. Not sure why.

Scala must not do this.

There’s nothing passed to the

test

function that tells the implementation of the function how to decide what B should be. So the type inference has nothing to work on.

Is type declaration meant to specify:

test

will return a supertype of A, but I don’t know which. Or is it meant to specify:

test

will return an A, but you can treat it as a supertype of A if you wish.

?

@Pavlo Liapota @natpryce I want to implement the class like with Scala’s Option. And I’m confused to implement to getOrElse function. It takes a type

[B >: A]

which means the type B is supertype of A. How can I implement this code to kotlin?

sealed abstract class Option[+A] extends Product with Serializable {
  self =>

    ... 
  @inline final def getOrElse[B >: A](default: => B): B =
    if (isEmpty) default else this.get
    ...

Here the

default

thunk you pass in lets the compiler bind the type of B. In the example above,

test

does not have an argument that lets the compiler know anything about B