Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[H. S. Teoh]

On Wed, Mar 25, 2020 at 11:12:46PM +0000, Jonathan Marler via Digitalmars-d wrote:
> On Wednesday, 25 March 2020 at 22:40:10 UTC, H. S. Teoh wrote:
> > 
> > Some of the latest new features like DIP1000 are in full force only
> > inside @safe code.
> > [...snip...]
> 
> Oh I didn't know DIP1000 was only enabled in @safe code.  Why is that?

I don't know if *all* of DIP1000 only applies in @safe code, I think
some of the fixes applies to @system code as well.  But the way I
understand it, the idea is that in @system code the programmer is
supposed to know what he's doing, and is assumed to be doing something
"outside the box" that the compiler does not fully understand, so by
default @system code is allowed to do seemingly "dangerous" things.
@safe code is for when the programmer is committed to doing only safe
operations, so that's where it makes the most sense to enforce these
checks.

I think the intention is that most D code will be @safe, and things like
DIP1000 will apply to enforce memory safety, and only when you need to
"go under the hood" you'd have a @system function as the escape hatch to
do the low-level hacks.  The way I read it, this is all part of a
general grand plan, which includes this DIP, to move towards having most
D code be @safe and only occasionally drop down to @system for
operations that cannot be mechanically verified.  Hence, @safe by
default.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis