Memory safety depends entirely on GC ?

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 24 13:44:47 PST 2015


On Tuesday, 24 February 2015 at 21:03:38 UTC, Walter Bright wrote:
> On 2/24/2015 11:12 AM, bearophile wrote:
>> I don't like the look of the annotations of DIP25. I'd like 
>> DIP25 removed from D
>> language and replaced by a more principled solution. Sometimes 
>> a heavier
>> solution can be simpler to understand (and it can be actually 
>> safe).
>
> So far, DIP25 has been called by various posters unprincipled, 
> hackish, and stupid, without supporting rationale.
>


I do think this comes from looking at the larger picture.

In isolation, DIP25 is not that bad. It solve a class of problems 
properly, which is already something. Where I think most people 
find it hacky, unprincipled, or whatever is when looking at the 
larger picture.

It seems obvious at this point that DIP25 is not the alpha and 
omega of the problem (this very thread is an example of this). 
For instance, DIP25 do not do anything for classes to be safely 
reference counted.

People are - legitimately - afraid that a set of DIP25 like 
solution will be adopted for each of these problems. When looking 
at the total cost of the set of solution, compared to a more 
complex, more principled solution, it seems that this is not the 
way forward.

In that sense, DIP25 seems like a hack to make reference counting 
work rather than the addition of a basic language feature that 
add a new dimension of expressiveness to the language. A bit like 
Rvalue references in C++ have been added to support std::move and 
std::forward instead of being a generally useful basic block to 
build upon.

> Note the thread "A Refcounted Array Type" thread, which uses 
> DIP25 to implement a memory safe ref counted container. It is 
> simple and requires exactly one annotation. It seems pretty 
> straightforward to me, and so far nobody has shown any holes in 
> it, or has even commented on the principle of it. (complaints 
> about bounds checking, delete, etc., are off-topic)

I still have to review it in details, but I'm sure this is good 
or at least fixable in a way that make it good.

Yet, as mentioned, the problem do not come with DIP25 in 
isolation. DIP25 does its job well. It just does a too limited 
job, and it seems that DIP25 and DIP25 like solution for other 
jobs, will ultimately lead to a more complex situation than where 
the 'too complex' solutions would lead us.


More information about the Digitalmars-d mailing list