Phobos is now compiled with -preview=dip1000

Olivier FAURE couteaubleu at
Sun May 19 00:04:05 UTC 2019

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:

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 

More information about the Digitalmars-d-announce mailing list