DIP 1008 Preliminary Review Round 1

[H. S. Teoh via Digitalmars-d]

On Fri, May 19, 2017 at 06:16:33PM +0000, Jack Stouffer via Digitalmars-d wrote:
[...]
> Instead, we should be asking
> 
> > How can allocations in Phobos and user code be transferred to an
> > allocation strategy of the user's choosing/needs?
> 
> If the user values code simplicity and safety, then the GC is fine,
> and template functions which allocate can then be marked as @safe due
> to their use of GC. But if the user needs other speed or usage
> requirements, then the user needs to offer something else, and that
> will automatically be marked as @system. I think that integrating
> std.allocator across Phobos in a consistent manner will allow this,
> where functions can accept allocators, and their internal allocations
> can all be done on the given allocator. This would also allow
> exceptions and other objects can be manually freed after a function is
> called if needed, or just left to the GC to collect if the GC
> allocator was passed to the function.

I agree with this, and having looked at std.experimental.allocator
recently, I think Andrei may even have made certain design decisions
with this in mind.  I think the ideal goal (I'm not sure how achievable
it is) would be to make theAllocator part of *druntime*, upon which you
can actually use array concatenations, AA's, etc., (almost) freely, and
the user would be able to control exactly how allocations would work. At
least in the current state of things, I don't see this as being
particularly possible due to various issues, the main one being that
code written with GC in mind generally does not track lifetimes, which
is a big obstacle to successfully being able to just assign a different
allocator to theAllocator and have things Just Work(tm).

Short of putting theAllocator in druntime outright, the next best thing
would be for all Phobos code to use it by default, eschewing any
constructs that might bypass it.  This seems more attainable, though it
does imply a LOT of churn in Phobos, and may require significant time
and effort to pull off.  Some Phobos code, of course, might be able to
take in allocators as template parameters or some such mechanism of
finer-grained control, but given the very large amount of code we're
dealing with, defaulting to theAllocator seems like a (slightly) more
reachable goal.


> In summary, I believe what Phobos needs is a wholistic approach to the
> problem of memory management, and not a bunch of small solutions over
> time.  To be sure, this is a much harder task, but I think if it's
> done right, with D we can have the first language which has compete
> user control to those who need it while offering ease of use to
> everyone else.

Yes, D needs to return to its original vision of getting the fundamental
design decisions right, rather than trying to retroactively patch over
existing flaws.  Otherwise, we risk becoming the next C++, which would
be a great pity.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra