OFF TOPIC Re: Range of enum type values

[Johan Engelen]

On Saturday, 28 December 2019 at 13:33:25 UTC, Timon Gehr wrote:
> 
> @safe is meant to imply no memory corruption. @safe implies no 
> UB, because UB can lead to any behavior, including memory 
> corruption. UB allows compilers to insert arbitrary code 
> execution exploits. How can you call that @safe?

I think we are talking about different things here.

You are saying: the spec says @safe means no UB, and if the spec 
doesn't say it then it simply needs updating. There are a number 
of text pieces that say that.

I am saying: regardless of what the spec and any of those 
articles promise, current D behavior is that @safe _can_ have UB 
in it.

I know most people don't like to hear it nor acknowledge it. But 
I think it is better to be realistic about this. `@safe` 
currently does _not_ mean the code is super safe.

One could say that the compilers are just not standard-compliant, 
nor is the spec itself, but the problem is bigger than that. 
Adding null dereference checks everywhere is not what (I think) 
people want. So that means there will always be UB potential in 
@safe code with interface method calls or class member variable 
access. I know about the "we specify that reading from NULL must 
result in a segfault". It misses the point by not understanding 
that a "null dereference" doesn't mean "access address 0" (let 
alone that by that we disallow e.g. system programmers to 
actually use address 0). Member variable access often does not 
access address 0x0, nor does an interface method call.

(I've been in these discussions too many times now. I'll try to 
stop arguing it.)

-Johan