-dip25 switch: time to make it always on?

[Walter Bright via Digitalmars-d]

On 7/2/2016 2:55 AM, Dicebot wrote:
> I have submitted a short summary of that ng.learn thread here :
> https://issues.dlang.org/show_bug.cgi?id=16228

Thanks! I'll fix them.


> My overall opinion of DIP25 is that it must not become part of language
> mainline for two reasons:
>
> 1) Implementation is not sufficiently mature (mostly diagnostics issues)

Of all the reports on it, there's nothing yet that makes it fundamentally wrong. 
Just a few garden variety bugs. Furthermore, none of the bugs resulted in any 
sort of corruption that was not in the code already without -dip25, i.e. it did 
no harm.


> 2) It targets a very niche use case and is too much of a language burden
> on its own - there are no interesting designs one can do with DIP25
> alone to "sell" the feature.

Since 'ref' is a critical feature, 'return ref' is needed to ensure that 
functions are not returning references to the stack. It's necessary for the 
fundamental 'identity' function to work safely.

You're right that there are no interesting designs that dip25 enables - there 
are no designs at all that dip25 enables. But that isn't it's purpose. It's 
purpose is to diagnose uses of ref that would cause corruption.

I don't understand why it would be a language burden. The idea behind this 
design is to require the user to add as few annotations as possible, and in this 
it has been (inadvertently according to deadalnix!) rather successful.

'return ref' is intended to provide safety without turning D into a B+D language.

All it really takes is finding one instance of memory corruption to make it 
worthwhile. I've lost many hours of my life searching for the causes of memory 
corruption. Recently on Reddit there were several tales of unsafe code costing 
corporations huge $$$$ in remedial action and innumerable customers suffered as 
malware blasted their systems. A solution is a big deal - even an incomplete 
solution is better than no solution. (Even though I fully intend to make D's 
solution complete.)


> In my opinion it should sit in a preview state until `return scope` or
> whatever replaces it gets finalized and tested and merged in main
> language simultaneously as parts of same feature.

'return scope' is coming soon. But that's a bigger cognitive leap, and is indeed 
a separate problem.

BTW, my work in applying @safe to Phobos modules has uncovered one overflow bug 
so far (and fixed). @safe, while incomplete, is far from useless.

As for being in a preview state, this thread amply demonstrates that is 
ineffective, as few to nobody even tries it. Maybe it would be more effective 
with a larger community.