What is value safety? Why should value constraints be pertinent here? near I can tell this is a neologism (introduced here? https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-...) that just happens to be near the top of search results in this area.
The introduction rule for enum values in C is _not_ type safe. You know how you can tell? Well typed programs go wrong. a language absolutely does not need value constraints of any kind to get this right.
Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe.
Yeah, any language with a type system worth its salt has value constraints, but if you choose to forego them as C and Go have, you're not going to bother adding them just for enums. It would be kind of silly to leave developers with a noose to hang themselves with everywhere else, but then think you need to tightly hold their hand just for enums.
In fact, I'd argue that if you are short on time and need to make compromises to reach a completion state, enums are the last place you would want to take the time to add value constraints. The types more often used would find much greater benefit from having value constraints.
Case in point: Typescript. When was the last time you cared that its enums behave just like C and Go? Never, I'm sure, because it having value constraints everywhere else more than makes up for it. Giving up value constraints for safer enums is a trade you would never consider.
> Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe
C’s type system is unsound, and not all compileable programs respect its dynamic requirements. We cope with this by referring to some code as “not type safe”.
foo bar = NOT_FOO;
You say this “typedef enum {…} foo” is not a type, naming a set of values, but just a convenient alias for whatever the representation is, thus all “enum” (regardless of actual decl) name the same set, and every constructor expression shares the same “type”. Consistent with the language specification, and passes the type checker, so you could say this code is “type safe”? but it’s one hell of a foible and not consistent with any lay (non PLT) understanding of type safety, where typesafety means the type written in the code and the runtime representation won’t desync (no runtime type errors).
If you simply forbid UB and refer to only strictly conforming programs, I will accept this modified meaning of “type safe”, but grumble that this meaning is not very good
edit to encompass parent edit: as a typescript nonprogrammer, I have nothing to add :) I am confused why you are putting the features in opposition. gradual + value-sensitive typing is a good feature, but doesn’t conflict with sums. in ocaml, we support both, real sum types as well as variant [`A | `B] etc that are structural in the way you’d want C to be
Along with every other programming language under the sun. A complete type system is not exactly an easy feat – especially if you want it to be usable by people.
> We cope with this by referring to some code as “not type safe”.
Value constraints are an application of types, so yes, if C/Go had value constraints then violation of those constraints would leave it to not be type safe. But they don't have value constraints. Insofar as what the types can constrain, the safety is preserved.
It seems all you are saying is that C (and Go) do not have very advanced type systems. But that shocks nobody. Especially in the case of Go, that was an explicit design decision sung by its creators. You'd have to be living under a rock to not know that.
Was there something useful you were trying to add?
> Was there something useful you were trying to add?
Yes, the clarification about value safety, which you’ve done quite well.
Not every language is unrepentantly unsound.
I continue to identify a confusion in this thread between a property of the languages, and a property of particular code, but I have clearly exhausted your patience. thank you.