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