so, playing around with inline class, I'm explorin...

# random

[elect]

so, playing around with inline class, I'm exploring their usage for enums (regarding c/c++ binding/port libs).
Inline enums are not yet available, however I'm somehow not complaining about this inside ^^.
From some early experience, I can tell you I seem to like more inline classes than inline enums because you can simply

inline class DrawMode(val i: Int)
val Triangles = DrawMode(GL_TRIANGLES)
...
fun glDrawArray(mode: DrawMode, count: Int) = ..

whenever I type `glDrawArray(`and I call for type completition all DrawMode top level members will be available and suggested as first ones.
I like this because I don't have to type glDrawArray(DrawMode.Triangles, ..). I know I can work on the import, but this is overhead for me.
Disadvantage, final user can of course implement it's own/additional DrawMode (not really a vs, since this gives the possibility for the user to add some newer enums from the latest API, where I still didnt catch on) and they are not guaranteed to be unique.
Do you see other differences? What's your feeling about this? I'm looking especially at you @gildor @karelpeeters @louiscad @diesieben07 🙂

[karelpeeters]

Final user being able to add their own (invalid) values is always going to be a problem with inline things, right? The real problem is that when statements aren't exhaustive with this, and that it's not immediately clear from docs that this is actually an enum.

[elect]

Just hit a big problem, the same variable name is used sometimes for different enums..

[elect]

and with inline classes this is a double conflicting declaration..

[elect]

another disadvantage, jvm signature conflict with different arguments list when most of params are ints

[elect]

regarding this aspect, enums wins easily