DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 20:56:28 UTC, Jonathan M Davis 
wrote:
> On Sunday, 11 October 2015 at 18:52:44 UTC, deadalnix wrote:
>> The only rebuttal to all of this is "Walter and I are happy 
>> with DIP25, and the fact of the matter", while everybody else 
>> is wondering what there is to be happy about.
>
> To be fair, you haven't really said much better. You're 
> claiming that it's clear that it's a failure, whereas Andrei is 
> saying that he doesn't see a problem with it. No concrete 
> arguments are being given. The closest is that you think that 
> the fact that we need something like DIP 74 means that DIP 25's 
> advantage of being simple is lost and that that somehow shows 
> that DIP 25 is a failure.
>

That's not true. I explained in this thread why it is too 
limited, most notably :

1/ It was barely able to provide a non GC managed array type.

More details here: 
http://forum.dlang.org/thread/mcg8qq$1mbr$1@digitalmars.com

Notably, it is impossible to reclaim the memory eagerly, but only 
to clean all memory at once when all reference to one of the 
memory location is gone. This in turn lead to the need to pretty 
much have a memory allocator in the array. And jump through many 
hoops.

2/ It is completely unable to handle reference types (hence 
DIP74).

Note that if you don't have indirection, there is no memory 
allocation problem to begin with as value type will be either on 
stack or involve some reference at some point.

But this whole thing is really a shift of the burden of proof. 
What do DIP25 enabled that is really worth it ?