On Saturday, 18 May 2019 at 19:44:37 UTC, Walter Bright wrote:
If all access to internals is returned by ref, those lifetimes
are restricted to the current expression.
Oh my god, I try my best to be open-minded, but talking about
dip1000 design with you is like pulling teeth *at best*.
Yes, containers work perfectly if you allocate them on the stack
and use their contents during the current stack frame, and then
de-allocate them statically. By definition, this represents 0% of
the use cases of dynamic containers.
Dynamic containers need methods like "push_back", "reserve",
"resize", "concatenate" or "clear", which are all impossible to
implement with dip1000 without making their implementations
trusted, which in turns opens up the program to use-after-free
memory corruption.
See also:
https://forum.dlang.org/post/qbbipvkjqjeweasxk...@forum.dlang.org
https://forum.dlang.org/post/rxmwjjphnmkszaxon...@forum.dlang.org
Have you talked to Atila Neves at all for the past six months?
Why the hell are we having this discussion?
This is not a new issue. I have raised it repeatedly in the past
(I can even dig up the posts if you're interested; I remember
writing a fairly in-depth analysis at some point). Atila's
automem and Skoppe's spasm have the same limitation: you can't
reallocate memory without writing unsafe code (I'm told spasm
gets around that by never deallocating anything).
Honestly, the fact that you're the only person with a coherent
vision of dip1000, and yet you keep ignoring problems when
they're pointed out to you is both worrying and infuriating. Eg:
So far, the only real shortcoming in the initial design was
revealed by the put() semantics, and was fixed with that PR
that transmitted scope-ness through the first argument.
Like, yes, I understand that dip1000 is an achievement even if it
doesn't allow for resizable containers, and that immutable
already allow for functional programming patterns and that's
great, but you need to stop acting like everything's going
perfect when community members (including highly involved library
writers) have complained about the same things over and over
again (imprecise semantics, lack of documentation, the resize()
use case) and you've kept ignoring them.
Seriously, I'm not asking for much. I'm not demanding you take
any architecture decision or redesign the language (like some
people are prone to demanding here). But it would be nice if you
stopped acting like you didn't read a word I wrote, over and over
again.
