Is there any planned approach for data validation ...

# language-evolution

[Jokubas Alekna]

Is there any planned approach for data validation during object construction with union type errors? I assume the current way of calling require(condition) will have to change. There is an issue on restricted types https://youtrack.jetbrains.com/issue/KT-68296/Union-Types-for-Errors, but I'm not sure if it covers the same use cases. The current approach of having invoke operators in companion objects seems quite janky, I wonder if language level features could improve the current state of constructors

[Youssef Shoaib [MOD]]

I think "smart constructors" (invoke in companion or top-level function with the same name as class) are here to stay. It would be interesting to see what replacement to require will emerge. Perhaps the simplest is to do:

if(!condition) return MyErrorType

[CLOVIS]

@Youssef Shoaib [MOD] that doesn't work in sub-functions, that's the problem. It's also a step back in readability (condition written in the opposite way, less explicit…)

For now, I'm not hyped about the union types proposal. Everything it does, Arrow does better.

[Javier]

I would like to have union type in general, not only for errors. I mean, just sugar to avoid creating sealed classes or interfaces all the time.

[CLOVIS]

Tagged and untagged unions are different. The Kotlin team has said they are against general untagged unions, but they said nothing about a shorthand syntax for tagged unions.