Opportunities for D

[Remo via Digitalmars-d]

On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
> Distilling the discussions about D that are elsewhere than this 
> forum, some consistent themes emerge which we need to address 
> to broaden the appeal of D. All of them require some 
> organization and focussed effort to complete.
>
> There's been enough jawboning about them. I figure all of them 
> can be smartly blown to smithereens if we just line up 3 or 4 
> cannons on each.
>
>
> 1. Ref Counting
>
> I believe that ARC is a pipe dream for D, as we've discussed 
> extensively here. But a ref counted object should work, and 
> would be very attractive, much like C++'s shared_ptr<T>.
>
>
> 2. Unique References
>
> unique_ptr<T> is another big success for C++. 2.066 has already 
> made big strides in inferring uniqueness of expressions, but it 
> doesn't go so far as creating a Unique!T type.
>
>
> 3. 'ref' means 'borrowed', to use Rust's terminology
>
> We're almost there with this. This means better escape 
> analysis, too.
>
>
> 4. Eliminating gratuitous use of GC in Phobos
>
> This means allocations that are not transmitted back to the 
> user. Here's an example of such: 
> https://github.com/D-Programming-Language/phobos/pull/2014
>
>
> 5. Precise and Concurrent GC
>
> There's been a lot of work on this, but I don't know where we 
> stand on it.
>
>
> 6. Pushing decisions about storage allocation upwards out of 
> Phobos
>
> By having functions write to OutputRanges instead of to GC 
> allocated buffers, the user can decide how to allocate the 
> storage.
>
>
> 7. "D-Routines" - goroutines for D
>
> Goroutines are the killer feature of Go for a number of 
> sensible people. We pretty much have this already with fibers, 
> but what is lacking is a scheduler, which will take some 
> effort, and a "Channel" type, which should be easy.
>
>
> 8. NotNull!T type
>
> For those that want a non-nullable reference type. This should 
> be doable as a library type.


All of this would be great, especially 1 and 2.

unique_ptr<T> is helpful in 90% of the time.
shared_ptr<T> is necessary in may be another 9%.
Memory pool is helpful in another cases.
And only in 0.1% case GC is really needed. :)

So how about memory pool for D ?
It there already one ?

> What about the already present std.typecons.Unique?

Unfortunately there are a lot of /+Doesn't work yet+/ comments in 
std.typecons.Unique code.