No, you cannot assume that all primitive values have a zero OR a one. For example, the structs you can define through FieldFlags.jl have no defined “default value”. They’re not even numeric at all, and don’t even have a zero initializer! There used to be one, but it caused some problems downstream precisely because assuming that all-zero is valid is not good.
That’s why I say that this is not possible for arbitrary T; you need to know what that T is to even be able to tell whether there could be a default value.
That veers more into the area of fuzzing (something one could do with PropCheck.jl, or soon better with an upcoming package of mine), but that brings its own problems - what if the constructor throws an error? Or worse yet, crashes julia? That’s not as absurd as it sounds, I’ve hit exactly that problem trying to do this before:
So if one doesn’t know how to construct a T and isn’t explicitly trying to fuzz a codebase, just generating a random “possibly valid” instance is going to lead to a lot of pain.
That’s true! To be clear, I think that is already pretty bad, and shouldn’t be made more likely by liberal use of Expr(:new), making the undef problem an issue for all T and not “just” Vector{T}
It’s the best known one, but the example is representative for all invariant-breaking usages of reinterpret. At least the docstring of reinterpret warns about this problem now.
