A modern programming language that makes developers happier.

kotlinlang

I was looking at the features of concurnas, and one thing I also wished to have in kotlin is to have the possibility on `Any` to overwrite a default `toBoolean()`.
This would by default evaluate `true` , for not nullable objects. (<https://www.concurnas.com/docs/controlStatements.html#toboolean>)
```class MyCounter(var cnt: Int = 0) {
  override toBoolean() = cnt &gt; 0
}
var counter: MyCounter? = null
if(counter) // -&gt; false
...
counter = MyCounter()
if(counter) -&gt; false
..
counter.cnt++
if(counter) -&gt; true
..```

But _why_? Do you often need it? What’s your domain you are writing code for?

It's quite common in 3d real time graphics (from C world) to check against null or 0 values for opengl objects (normally `int`s), for example

<@U2H3SABQF> could that logic be encapsulated in an extension function on Any? Check for null, if it's not then evaluate for true/false as you normally would.

But I'd like the language to do the boilerplate code for me

Closed classes are a core part of Kotlin and is one reason why I use the language. I get the feeling this functionality would break that

All classes are final by default in Kotlin, open is opt-in. Overwriting `toBoolean` on `Any` could have unintended consequences. One example I can think is third party libraries, if they overwrite the functionality would it cascade into my app? If two overwrite the functionality which one would win out?

I may be misunderstanding this as well, but that case in particular has me a little concerned.

if you overwrite that method than of course it can have unintended consequences.

Before you do that you should of course check intended use, documentation and actual usages

Nothing more and nothing less than overwriting any other method

let's be clear, I mean overwriting it in the implementation classes..

Could you add a `.check()` extension method to each of the relevant classes? That way, you won't ever actually count on a `toBoolean()` call on an object that's actually using the default non-null check instead of the check you want.
The behavior you're asking for exists in Python, but it's problematic. You may think you're checking if an arbitrary object is null, but wait, it's a list, so you're actually checking if it's empty as well! Having specific `.check()` methods may avoid this, the relevant method would always be known at compile-time instead of runtime.

then you shouldnt use it for nullable lists

&gt;  shouldn't use it for nullable lists
Goes against Kotlin's design philosophy IMO. My counter argument will always be "if I am allowed to do something, I will do it" so if I'm allowed to do something but I really shouldn't the system should be designed in such a way that I just can't do it.

there is always the possibility to mess up the language in unortodox ways

forbidding features in legit scenarios because people might misuse them in other ones is a weak and wrong principle

this is a pretty common schema when dealing with graphic apis, such as OpenGL or Vulkan