just not worth for my case

# random

[elect]

just not worth for my case

[elizarov]

Can you share the code you are working on somewhere or at least relavant bits of it? I want to take a look at the larger context, not just bits.

[elizarov]

We are trying tackle the desing of bitwise ops for Kotlin. Adding C-style operation is an obvious solution, but we fear its extreme abuse potential and are looking for alternatives that might make the code just a readable, but w/o all the downside of a special set of operators for extremely small minority of code.

[elect]

gladly, I'd point especially the enum class that forced me to revert the EnumSet usage

[elect]

https://github.com/kotlin-graphics/imgui/blob/master/src/main/kotlin/imgui/enums.kt#L335

[elect]

the more tricky ones were the internal ones, (the four types at the end, starting with an underscore, that represents multiple coloredit flags)

[elect]

and this is one code chunk where using EnumSet just couldn't keep up, https://github.com/kotlin-graphics/imgui/blob/9b86cb1f31ae92d5bdf5fb227ffe723d2a6faade/src/main/kotlin/imgui/imgui/widgetsColorEditorPicker.kt#L98-L111

[elect]

code lines just exploded and code design was completely different from the original, harming the manteinance and synchronization with the c project

[elect]

I understand your fear, but I am always convinced that holding a feature because its potential abuse is always a poor and losing choice. There are many way one can abuse and write bad code with all the things that are available today. Moreover, bitwise operations is predominant in 3d graphics (all the major project I am working on make heavy use of it: imgui, assimp, glm, gli, openvr,..) and for (android) UIs (like colors).

One of the points that sold me to Kotlin was the operator overloading. It dramatically increase the readability of many parts of my code.

I don't think a couple of simple overloading operators, ! & | ^ ~ << >> on primitives, or at least on `Int`s, will cause more harm than benefits.
Look at all the major languages out there: c, c++, java, go, rust, switft, javascript, php, etc... All of them have them.

There are some kotlin killing features that are being studied and implemented like the nullability handling. Not having bitwise operator not. There'd be a reason I say... 🙂

[elizarov]

I’d say that potential for abuse is not the main hold back. The very small fraction of code that actually needs it is.

[elizarov]

So, I see that you’ve defined this set of functions:

infix fun Int.or(other: Cond) = this or other.i
infix fun Int.has(b: Cond) = (this and b.i) != 0
infix fun Int.hasnt(b: Cond) = (this and b.i) == 0
infix fun Int.wo(b: Cond) = this and b.i.inv()

[elizarov]

Have you tried working with them? Are they convenient? Would just adding them to stdlib be enough to make it easy to work with bitsets in practice?

[elizarov]

“adding them to stdlib” I mean this:

infix fun Int.has(b: Int) = (this and b) != 0
infix fun Int.hasNot(b: Int) = (this and b) == 0
infix fun Int.wo(b: Int) = this and b.inv()

[elect]

Yeah, I've been working. They are convenient given the current situation (ie no bitwise operators).
I also tried the EnumSet option, after spending a whole day, it didnt work, I had to revert everything back

[elect]

the only downside is that they are still literal and I have to basically re-implement everytime I have to define a new enum

[elect]

apart from that, I'd say has and hasnt have been prooved to be more redable, even more because they play nice with operator priority, ie: } else if (flags has Cef.HEX && flags hasnt Cef.NoInputs) {

[elect]

even though a !has would be perfect (but this is another issue.. 🙂 )

[elect]

thanks to a suggestion from @gildor, I'm also mitigating the verbosity thanks to import renaming (importing the whole enum wasnt an option)

[groostav]

@elect

this is another issue

this is literally true:
https://youtrack.jetbrains.com/issue/KT-5351

[elect]

yeah I know, I'm already in also there 😬