> Not sure about C#, but in Java if you write `sealed` correctly you won't need the catch-all throw.

Will the compiler check that you have handled all the cases still? (Genuinely unsure — not a Java programmer)

> With your shape example, you cannot express in the type system "this function won't return a point".

Sure you can, that's just subtyping. If it returns a value that's not a point, the domain has changed from the shape type and you should probably indicate that.

  structure Shape = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point
  end

  structure Bound = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
  end

That's not to say it's the only way to solve this problem, though. And for heavy-duty problems, you typically write something like this using higher-kinded polymorphism:

  signature SHAPE_TYPE = sig
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point

    val Circle : real -> shape
    val Rectangle : real * real -> shape
    val Point : shape
  end

  functor FullShape () : SHAPE_TYPE = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point

    val Circle = Circle
    val Rectangle = Rectangle
    val Point = Point
  end

  functor RemovePoint (S : SHAPE_TYPE) :> sig
    type shape
    val Circle : real -> shape
    val Rectangle : real * real -> shape
  end = struct
    type shape = S.shape
    val Circle = S.Circle
    val Rectangle = S.Rectangle
  end


  structure Shape = FullShape()
  structure Bound = RemovePoint(Shape)

Anyways, in both cases, this is now just:

  DoesNotReturnPoint : Shape.shape -> Bound.shape

> If they're not actual sum types but are pretty much the same, what good does the "actually" do?

Conflation of two different things here. The examples given are syntactically similar, and they're both treating the constituent part of the grammar as a tagged union. The case isn't any cleaner was the point.

However in the broader comparison between class hierarchies and sum-types? They're not similar at all. Classes can do some of the things that sum-types can do, but they're fundamentally different and encourage a completely different approach to problem-solving, conceptualization and project structure... in all but the most rudimentary examples. As I said, my 2nd example here is far closer to a class-hierarchy system than sum-types, though it's still very different. And again, underlining that because of the properties of sum-types, thanks to their specific formalization, they're capable of things class hierarchies aren't. Namely, enforcing valid program-states at a type-level. Somebody more familiar with object-oriented formalizations may be a better person to ask than me on why that is the case.

It's a pretty complicated space to talk about, because these type systems deviate on a very basic and fundamental level. Shit just doesn't translate well, and it's easy to find false friends. Like how the Japanese word for "name" sounds like the English word, despite not being a loan word.

- You can use GADTs (https://ocaml.org/manual/5.2/gadts-tutorial.html) and indexes to give a concrete type to every constructors:

  ```ocaml
  type _ treated_as = 
   | Int : int -> int treated_as
   | Float : float -> float treated_as

  let f (Int x) = x + 1 (* val f : int treated_as -> int *)
  ```

  ```ocaml
  let f = function 
  | `Foo x -> string_of_int (x + 1) 
  | `Bar x -> x ^ "Hello"
  (* val f : [< `Foo of int | `Bar of string] -> string` *)

  let g = function
  | `Foo _ -> ()
  | _ -> () 
  (* val g : [> `Foo of 'a ] -> unit *)
  ```

And since OCaml has also an object model, you can also encoding sum and sealing using modules (and private type abreviation).

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.