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