Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/11/2016 11:57 AM, deadalnix wrote:
> Alright, but keep in mind that is an example, not the actual problem I'm
> talking about. There are many reasonable way to make the example above
> safe: disallow dereferencing pointers from unknown source,

Once you're in @safe code, the assumption is that pointers are valid. 
Unknown sources are marked @trusted, where the programmer takes 
responsibility to ensure they are valid.


> do a bound check on .ptr, disallow .ptr altogether and much more.

The PR disallows .ptr in @safe code. The @safe alternative is &a[0] 
which implies a bounds check.


> The root problem is that "@safe guarantee memory safety and if it
> doesn't it is a bug" provides no information as to what is the bug here
> and no actionable items as to how to fix it, or even as to what needs
> fixing.

It's kind of a meaningless criticism. Any piece of code has a bug if it 
doesn't meet the specification, and there's no way to verify it meets 
the specification short of proofs, and if anyone wants to work on proofs 
I'm all for it.

In the meantime, please post all holes found to bugzilla and tag them 
with the 'safe' keyword.