On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
...
I have already made my objections known in the other threads, but I'll list them here for posterity.
Firstly, and most importantly IMO, this does not solve the surface level problem, which is the lack of @nogc in much of Phobos. While the DIP is correct that in a lot of the absence of @nogc is due to exceptions, most notably the auto decoding functions in std.range, it not the only reason. There are many things in Phobos which stop @nogc, such as array literals, array appending, AAs, and delegates. While many functions can be made @nogc via this change, there will be many functions left in Phobos still allocating, and this is a major problem in my estimation. The reason I take this all or nothing view of the situation is that @nogc exists largely for a group of people who want to avoid the GC __completely__. If lack of any GC usage is actually a requirement for a project, having many very useful parts of Phobos off limits (a few that spring to mind are bigint, digest, and a lot of stdio) is still a problem when our competitors in this GC free arena are Rust and C++ which will both have a lot more functionality in this limited scope.
Secondly, I'm not a fan of special casing syntax, especially when I don't think the given benefits outweigh the above listed costs. Making operator new do something completely different in one specific context is a continuation of the trend in the recent past of making the language more and more complicated, which I find troubling as one of D's main selling points is it's practicality and its low learning curve.
And while I don't think the code breakage will be a huge problem, it still is something to consider when asking what are we getting for all of these costs.
Thirdly, I don't think the DIP asks the right question. The DIP asks
How can we make exceptions, and thereby many Phobos functions, @nogc?
IMO the right question to ask is a level of analysis above that. As already mentioned, there are many things which will still be allocated on the GC. We need to fix these as well if we want to market D as a GC optional language. 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.
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.
