Sum types in Pascal are called variant records:
type
FooKind = (Foo, Bar, Baz); (* An enum *)
FooOrBaz = record (* This is the sum type *)
case foo: FooKind of
Foo: (quux: Double);
Bar: (zot, zap: Double);
Baz: (xyzzy: String);
end
As for Go, my full opinion on that subject may be found here. If you're... curious. Let's say.
This is the exact same thing, except in addition to the tag there is also a data component. Yes, this is the more traditional representation of sum types, but having an "undefined" data component is still identifiable as a sum type. It’s the tag in the union that makes it a sum type.
In Typescript terms, which I think illustrates this well, it is the difference between:
{ kind: 0 } | { kind: 1 }
{ kind: 0, data: T } | { kind: 1, data: U }
> They are an enumeration of discrete values
Yes, the "tag" is populated with an enumerator. There is an enumerator involved, but is outside of the type system. It's just an integer. The additional information you can gain from it, like exhaustive matching, comes at the type level.
There are innumerable ways you can rectify this lack of understanding if you want to.
1. If you have a pet sum type definition, let it be known. But traditionally, a sum type is better known as a discriminated or tagged union. So far, this is what we understand Pascal offers: A union type that discriminates its subtypes by an enumerated value.
2. The tag that discriminates the type within the union (or whatever your explanation above ends ups calling it) is, in implementation, generated by a process that assigns a number to each entity; something also true of Rust. This is undeniable, as proven by the use of Ord and mem::discriminant. If you have another name for that numberer, if not an enumerator, let it be known.
Normally in Pascal you would not match on the enumeration at all, but rather on the sum types.
The only reason for enumerations in Pascal (and other languages with similar constructs) is because under the hood the computer needs a binary representation to identify the type, and an incrementing number (an enum) is a convenient source for an identifier. In a theoretical world where the machine is magic you could have the sum types without enums, but in this reality...Thus, yes, in practice it is possible to go around the type system and get the enumerated value out with Ord(foo), but at that point its just an integer and your chance at exhaustive matching is out the window. It is the type system that allows more flexibility in what the compiler can tell you, not the values generated by the enumeration.
> Go only has enums by convention
"Enums by convention" would be manually typing 1, 2, 3, 4, etc. into the code. Indeed, that too is an enumeration, but not as provided by the language. Go actually has enums as a first-class feature of the language[1]. You even say so yourself later on, so this statement is rather curious. I expect you are confusing enums with sum types again.
[1] Arguably Pascal doesn't even have that, only using enums as an implementation detail to support its sum types. Granted, the difference is inconsequential in practice.