RFC: moving forward with @nogc Phobos

[via Digitalmars-d]

On Tuesday, 30 September 2014 at 12:02:10 UTC, Johannes Pfau 
wrote:
> That's possible but insanely dangerous in case you forget to 
> reset the
> thread allocator. Also storing stack pointers in global state 
> (even
> thread-local) is dangerous, for example interaction with fibers 
> could
> lead to bugs, etc. (What if I set the allocator to a stack 
> allocator
> and call a function which yields from a Fiber?).
>
> You also loose all possibilities to use 'scope' or a similar 
> mechanism
> to prevent escaping a stack pointer.

Yes, I agree. One option would be to have thread-local region 
allocator that can only be used for "scoped" allocation. That is, 
only for allocations that are not assigned to globals or can get 
stuck in fibers and that are returned to the calling function. 
That way the context can free the region when done and you can 
get away with little allocation overhead if used prudently.

I also don't agree with the sentiment that allocation/management 
can be kept fully separate. If you have a region allocator that 
is refcounted it most certainly is interrelated with a fairly 
tight coupling.

Also the idea exposed in this thread that release()/retain() is 
purely arithmetic and can be optimized as such is quite wrong. 
retain() is conceptually a locking construct on a memory region 
that prevents reuse. I've made a case for TSX, but one can 
probably come up with other multi-threaded examples.

These hacks are not making D more attractive to people who find 
C++ lacking in elegance.

Actually, creating a phobos light with nothrow, nogc, a light 
runtime and basic building blocks such as intrinsics to build 
your own RC with compiler support sounds like a more interesting 
option.

I am really not interested in library provided allocators or RC. 
If I am not going to use malloc/GC then I want to write my own 
and have dedicated allocators for the most common objects.

I think it is quite reasonable that people who want to take the 
difficult road of not using GC at all also have to do some extra 
work, but provide a clean slate to work from!