We have proposed a restriction No_Dynamic_Accessibility_Checks in AI22-0076-2. In a recent comment, it was suggested we change the name to "Static_Accessibility_Checks" to emphasize that, where the restriction applies, we are requiring all accessibility checks to be statically checkable. This suggestion then leaves the issue of whether run-time checks are performed as well as an optimization issue.
With that as a backdrop, and with discussion of whether "optional" types should require explicit "unwrapping" of such types, plus the idea of generalizing case statements so that it can be used to check for null vs. not null, and that a particular choice could have a label to introduce a new local view of the tested object, we have the pieces necessary to consider generalizing this notion of a restriction that requires certain constructs to be statically checkable. In particular, we might suggest restrictions such as Static_Null_Checks and Static_Index_Checks, or conceivably All_Checks_Static.
To be more concrete, imagine we have a value of an access type that might or might not be null. A generalized case statement would allow us to check on the nullness of the access value as follows:
case X is
when null =>
...
when NN : not null => -- introduce a name N for the "not null" view of X
NN.A := 3; -- statically checkable that the null check will pass
end case;
This would provide safety guarantees similar to those of languages that require some sort of explicit "unwrapping" operation before dereferencing a potentially null pointer, or equivalent.
A similar example would be checking that an array index is within range:
case I is
when IR : A'Range =>
A(IR) := 42; -- statically checkable that the index check will pass
when others =>
...
end case;
The idea of imposing a restriction such as Static_Null_Checks or Static_Index_Checks would be that an explicit test must be used to guarantee that a given sort of check will pass. The intent is that the generalized case statement (AI22-0153-1) would be the most common way to ensure staticness, by taking advantage of its ability to give a local name to the particular case choice that guarantees safety.
We have proposed a restriction No_Dynamic_Accessibility_Checks in AI22-0076-2. In a recent comment, it was suggested we change the name to "Static_Accessibility_Checks" to emphasize that, where the restriction applies, we are requiring all accessibility checks to be statically checkable. This suggestion then leaves the issue of whether run-time checks are performed as well as an optimization issue.
With that as a backdrop, and with discussion of whether "optional" types should require explicit "unwrapping" of such types, plus the idea of generalizing case statements so that it can be used to check for null vs. not null, and that a particular choice could have a label to introduce a new local view of the tested object, we have the pieces necessary to consider generalizing this notion of a restriction that requires certain constructs to be statically checkable. In particular, we might suggest restrictions such as Static_Null_Checks and Static_Index_Checks, or conceivably All_Checks_Static.
To be more concrete, imagine we have a value of an access type that might or might not be null. A generalized case statement would allow us to check on the nullness of the access value as follows:
This would provide safety guarantees similar to those of languages that require some sort of explicit "unwrapping" operation before dereferencing a potentially null pointer, or equivalent.
A similar example would be checking that an array index is within range:
The idea of imposing a restriction such as Static_Null_Checks or Static_Index_Checks would be that an explicit test must be used to guarantee that a given sort of check will pass. The intent is that the generalized case statement (AI22-0153-1) would be the most common way to ensure staticness, by taking advantage of its ability to give a local name to the particular case choice that guarantees safety.