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.
