D-ark corners - algorithms, ranges, and auto ref - best practices guides.

[H. S. Teoh]

On Wed, Jul 24, 2019 at 07:06:07AM +0000, aliak via Digitalmars-d wrote:
> On Tuesday, 23 July 2019 at 17:17:25 UTC, H. S. Teoh wrote:
[...]
> > Isn't this precisely the sort of problem dip25 / dip1000 are
> > supposed to catch?  Are you compiling with -dip25 -dip1000?  Are
> > DIP25/DIP1000 (or their current implementations) not catching this
> > particular case for some reason?
[...]
> Not compiling with those no.

You probably should, if you're relying on @safe in any significant way.


> Is @safe supposed to solve all memory corruption or is it only if
> dip1000 and dip25 is on. So default @safe is not @safe?

@safe is *intended* to prevent memory corruption.  But there are some
loopholes in the current implementation, which are addressed by DIP1000
and DIP25.  AIUI, the intention is that -dip25 and -dip1000 will
eventually be the default behaviour; we're just in the transition period
right now because they could potentially break existing code (as in,
they will cause compilation errors to otherwise working code).  So in
the meantime, if your code doesn't break with -dip25 -dip1000, you
should probably just compile with them by default in order to get the
benefits of a better @safe implementation.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long