Comment by tgv
2 days ago
Sure, but you want restrictions. You can't get an annotation that magically eliminates (de)allocation errors. It comes at a cost. The advantage of this particular proposal is its simplicity, I think. Otherwise, you'd have to get into contracts with complex expressions and then you'll have to prove those expression hold, and before you know it, your program is filled with proof statements. At least, that's my (limited) experience in SPARK, where you even can't have pointers.
My point is can you write a json deserializer with this, where allocation of every child is defacto optional, depending on input JSON?
As long as the verifier can be satisfied by wrapping the different results in a common type you should be fine. There has to be some way to appease it in that scenario as otherwise even trivial programs wouldn't be able to pass.