https://kotlinlang.org logo
#language-evolution
Title
# language-evolution
l

Luke

03/01/2023, 9:31 PM
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:
Copy code
val String.isValidUrl: Boolean get() = TODO()
fun areValidCredentials(email: String, password: String): Boolean = TODO()
Then, could the compiler generate:
Copy code
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.
d

dmitriy.novozhilov

03/01/2023, 9:37 PM
IMO this is the task not for the compiler but for compiler plugin
l

Luke

03/01/2023, 9:51 PM
Would it be possible with a plugin? I did consider it but I don't have good knowledge about those, especially coding one 😅
c

Casey Brooks

03/01/2023, 10:07 PM
You could probably make a KSP plugin to generate these negated functions https://kotlinlang.org/docs/ksp-overview.html
e

elizarov

03/02/2023, 4:17 PM
IMO, KT-5351 syntax is way cooler than having to generate methods.
l

Luke

03/02/2023, 9:44 PM
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
e

elizarov

03/03/2023, 8:14 AM
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.
i

ilya.gorbunov

03/03/2023, 10:05 PM
@elizarov KT-5351 has that different proposal as well, see the comments, but there are also some concerns about new ambiguities it can introduce
e

elizarov

03/04/2023, 1:41 PM
Thanks. Indeed it is all in the discussions of KT-5351. I somehow thought it was in a separate issue.
9 Views