Would it be possible/interesting to have the compi...

# language-evolution

[Luke]

Would it be possible/interesting to have the compiler generate the negation of boolean variables and functions that return booleans? For example, let's say this is defined:

val String.isValidUrl: Boolean get() = TODO()
fun areValidCredentials(email: String, password: String): Boolean = TODO()

Then, could the compiler generate:

val String.isNotValidUrl: Boolean inline get() = !isValidUrl
fun areNotValidCredentials(email: String, password: String): Boolean = !areValidCredentials(email, password)

The name could be changed via annotation, or by default the compiler wouldn't do anything but adding an annotation with an optional name could generate the negations..?

I feel it would make code more readable than having the ! before or .not() after. The standard library already has some negated function such as List.isNotEmpty, so I feel Kotlin could improve by generalizing this trend.

[ephemient]

https://youtrack.jetbrains.com/issue/KT-5351/Short-syntax-for-negation-with-infix-call

[dmitriy.novozhilov]

IMO this is the task not for the compiler but for compiler plugin

[Luke]

Would it be possible with a plugin? I did consider it but I don't have good knowledge about those, especially coding one 😅

[Casey Brooks]

You could probably make a KSP plugin to generate these negated functions https://kotlinlang.org/docs/ksp-overview.html

[elizarov]

IMO, KT-5351 syntax is way cooler than having to generate methods.

[Luke]

Well... I mean... Yeah it's cool, but it only affects infix functions. It doesn't help for example if you have a chain of operations ending with one that returns a boolean. The ! operator would be far from the function, and .not() is not as readable as having isNotEmpty() for example, or isInvalid vs isValid.not(). But that's just my opinion

[elizarov]

Sorry. I was thinking about a different proposal which I cannot even find now. The idea was floating around to allow writing someChainOfCalls.!isEmpty() which reads very much like someChainOfCalls.isNotEmpty() without having to have a separate isNotXxx version for every isXxx function.

[ilya.gorbunov]

@elizarov KT-5351 has that different proposal as well, see the comments, but there are also some concerns about new ambiguities it can introduce

[elizarov]

Thanks. Indeed it is all in the discussions of KT-5351. I somehow thought it was in a separate issue.