now, if we could have also bitwise operators it'd ...

# random

[elect]

now, if we could have also bitwise operators it'd be the best metal

[louiscad]

I wrote a few of those: https://github.com/LouisCAD/Splitties/blob/master/bitflags/src/main/java/splitties/bitflags/BitFlags.kt

[elect]

I have something similar but shorter: has, hasnt, or, and, wo (without)

[elect]

and I'm forced to do this for almost each enum, https://github.com/kotlin-graphics/imgui/blob/master/src/main/kotlin/imgui/enums.kt#L79-L82

[elect]

I couldnt come up yet with a better alternative

[elect]

the dual representation in C/C++ between enum and int is really enviable

[elect]

I wish we could have something similar in Kotlin

[gildor]

But why do you need enum in this case instead of just object with constants?

[elect]

I also explored the EnumSet possibility, but that's not an option for me. Too many code border, instantiations and style difference from original C port

[elect]

because I want to infer also type safety

[gildor]

but why do you need int and all those flags than? Just use set of enums.
And use standard methods of set, instead of converting to/from enum

[gildor]

Of course set requires more memory than single int, but also will be easier to use and much more type-safe

[elect]

what do you have in mind, Andrey?

[elect]

I usually have enum class WindowFlag and typealias WindowFlags = Int to help understanding on which enum set an int mask is based from

[elect]

you meant EnumSet, didn't you?

[gildor]

Why do you use int instead of enums for preferences? Because of performance?

[gildor]

EnumSet for example, yeah, it’s slightly more efficient than just general usage Set

[elect]

because I have a massive usage of enums

[gildor]

I didn’t get your point

[gildor]

So if you have a lot of enums, use them as enums, not as int representation

[elect]

and that would require too many EnumSet instantiations and style difference compare to the C code

[elect]

the enums allow me to also use the int counterpart wherever I need that and there is no additional instantiation overhead

[elect]

and it closer to the C version I do the port from

[gildor]

Why style should be the same as for C?
why
window.flags += ShowBorders
is worse than
window.flags |= ShowBorders.i

[gildor]

wherever I need that

Enum already has ordinal property which is int representation of enum

[elect]

That's an easy example, but when I tried that there were some complicate passages where I had to completely change the original line style (and this is also quite error prone)

[elect]

I can take advantage of ordinal only when the corresponding enum is supposed to start from 0 and increase contiguously. Unfortunately this is not always the case

[elect]

so I have an additional .i field for that

[gildor]

Yeah, maybe in terms of porting is make some sense, you just want to port with minimal effort

[elect]

exactly

[elect]

maybe inline classes would bring some new possibilities

[gildor]

But my point, that probably for pure Kotlin code without this attempt to keep style for another language, I would rather use Enum directly

[elect]

I'm really looking forward for those

[elect]

yeah, definitely

[gildor]

Unfortunately, as I understand, inline enum classes will not be available on first implementation. You can check KEEP and maybe add your cases

[gildor]

Also, interesting paragraph from EnumSet docs:

Enum sets are represented internally as bit vectors. This representation is extremely compact and efficient. The space and time performance of this class should be good enough to allow its use as a high-quality, typesafe alternative to traditional int-based “bit flags.” Even bulk operations (such as containsAll and retainAll) should run very quickly if their argument is also an enum set.

[gildor]

So I would really take a look into it. Int is definitely more efficient, but one more object probably wouldn’t be a problem, especially so efficient implementation

[gildor]

Also EnumSet handles enums for more than 64 options automatically

[elect]

you are so tempting, Andrey ^^

[elect]

ah, another issue with EnumSet is that on C, when you pass flag you pass a copy, on JVM I'd pass the reference to the class. That was another big error prone point

[elect]

I'd have to create a copy everytime I pass it to another function -> more instantiations

[gildor]

Yes, instantiation of one object with one int field, of course if it’s real problem than you on the stage when for optimization reasons you should do your code ugly
But I would really concider this option. It’s actually the same price as for boxing Int, also one object with Int field, and probably even more efficient than creation of single string.
And because this is probably public API, maybe make sense to make it even more user friendly and type safe and pay price of a couple objects per component

[elect]

Anyway Andrey, looking at the inline proposal one use cases is "inline enum classes", https://github.com/Kotlin/KEEP/blob/master/proposals/inline-classes.md

[elect]

this is exactly also my use case! I cant wait

[gildor]

Yes, I know, I saw this in proposal, but enums mentioned only as "use case", no details about implementation, but would be happy to see this as part of the first implementation