DIP 1008 Preliminary Review Round 1

[Jack Stouffer via Digitalmars-d]

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.