> Slightly more verbose sum type declaration is worth it *when it makes using the cases cleaner.*

Correct. This is not the case when you talk about Java/Kotlin. Just ugliness and typical boilerplate heavy approach of JVM languages.

▲

ackfoobar 5 days ago | parent | next [-]

> Just ugliness and typical boilerplate heavy approach of JVM languages.

I have provided a case how using inheritance to express sum types can help in the use site. You attacked without substantiating your claim.

▲

wiseowise 5 days ago | parent [-]

Kotlin's/Java's implementation is just a poor man's implementation of very restricted set of real sum types. I have no idea what

> This has the benefit of giving you the ability to refer to a case as its own type.

means.

▲

ackfoobar 5 days ago | parent [-]

> I have no idea

I can tell.

Thankfully the OCaml textbook has this explicitly called out.

https://dev.realworldocaml.org/variants.html#combining-recor...

> The main downside is the obvious one, which is that an inline record can’t be treated as its own free-standing object. And, as you can see below, OCaml will reject code that tries to do so.

▲

wiseowise 5 days ago | parent [-]

That's for embedded records. You can have the same thing as Kotlin but with better syntax.

	▲	ackfoobar 5 days ago \| parent [-]
		If you don't do inline records you either - create a separate record type, which is no less verbose than Java's approach - use positional destructuring, which is bug prone for business logic. Also it's funny that you think OCaml records are "with better syntax". It's a weak part of the language creating ambiguity. People work around this qurik by wrapping every record type in its own module. https://dev.realworldocaml.org/records.html#reusing-field-na...

▲

gf000 5 days ago | parent | prev [-]

You mistyped "backwards compatible change" going back to close to 3 decades.