Discussion Thread: DIP 1035-- at system Variables--Community Review Round 2

[Paul Backus]

On Saturday, 27 February 2021 at 20:54:34 UTC, Steven 
Schveighoffer wrote:
> D is perfectly within its rights to do whatever it wants for 
> @safe code. It could let you write an array length without 
> extending the array, and then only allow you accessing the 
> single element pointed at. It could prevent dereferencing 
> pointers, and still be considered memory-safe. But there is 
> still the question of whether this is useful to programmers or 
> not.

The general trend in the design of @safe, as exemplified by DIP 
25 and DIP 1000, has been to lift restrictions when the compiler 
can prove they are not necessary to prevent UB. And I would argue 
that this is exactly what one wants in a proof system: the 
strongest result (memory safety) from the fewest axioms 
(restrictions on @safe code).

Another way to look at it is that automatically extending an 
array when its length is changed allows the compiler to prove 
memory safety for programs that would otherwise require @trusted, 
so it is a useful restriction. On the other hand, forbidding 
access to safe members of unions does not make any 
previously- at trusted programs @safe, so it is a useless 
restriction.

I understand from previous discussions that you have some 
less-rigorous ideas about what is "useful to programmers" and 
what is not, but I think this is an occasion where rigor is 
warranted.