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.

Walter Bright:

> but it doesn't go so far as creating a Unique!T type.

What about the already present std.typecons.Unique?


In your list I'd like to add another point:
9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named "unapply").

Bye,
bearophile

Walter Bright:

> 3. 'ref' means 'borrowed', to use Rust's terminology
>
> We're almost there with this. This means better escape analysis, too.

Is "scope" still left for future usage, or used for a different purpose, or deprecated?

Bye,
bearophile

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.

Remo:

> 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. :)

Are you forgetting the RefCount?

But I use D because it has a GC and it doesn't look like C++, I am not writing device drivers or an operating system, I am OK with a language less efficient than C++ if it gives easier to write code, more compact code, less noisy code, much less bug-prone code.

In C++11 you have over-engineered lambdas because there is no GC, D GC rely on the GC and sometimes allocate on the heap. I don't want the very bad syntax and semancits of C++ lambdas in D. Closures and lambdas are quite common in the D code I write. How do you concatenate built-in arrays without GC? And so on...


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

Andrei is working a lot on them. They look very good.

Bye,
bearophile

On Tuesday, 8 July 2014 at 22:56:56 UTC, bearophile wrote:
> Remo:
>
>> 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. :)
>
> Are you forgetting the RefCount?

shared_ptr<T> uses reference counting.
http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_ptr.htm

> But I use D because it has a GC and it doesn't look like C++, I am not writing device drivers or an operating system, I am OK with a language less efficient than C++ if it gives easier to write code, more compact code, less noisy code, much less bug-prone code.
>

I do not saying that GC is always bad.
The future C++ standard will get GC too.
It is strange but some peoples (not C++ programmers) think that D looks too much like C++ and this is bad :)
For this is advantage that D looks a bit like C++ and can interact/work with C/C++ !

I like a lot of D features.
Templates for example are probably easier to write in D as in C++, but I still do not have problems with them in both languages.

So if I want to write a simple tool then I would use D2 instate of C++.
But everything (like a 3D Renderer) that need to be as fast as possible can still only be written in C++.

> In C++11 you have over-engineered lambdas because there is no GC, D GC rely on the GC and sometimes allocate on the heap. I don't want the very bad syntax and semancits of C++ lambdas in D. Closures and lambdas are quite common in the D code I write.

Well yes may be the lambdas syntax in C++ is not the best but it is still great addition to the language.

> How do you concatenate built-in arrays without GC? And so on...

The same way one do this in C++ ?
Copy second array at the end of the first one.
If there is not enough free space in the fist array (a) then.
Allocate new array bigger as size of (a+b) and copy array (a) and (b) to the new memory, then free old memory.
This work reasonable well for std::vector<T> .

And how this will be done with GC ?

>> So how about memory pool for D ?
>> It there already one ?
>
> Andrei is working a lot on them. They look very good.

Is the code public already ?

> Bye,
> bearophile

On Tuesday, 8 July 2014 at 23:18:53 UTC, Remo wrote:
>>> So how about memory pool for D ?
>>> It there already one ?
>>
>> Andrei is working a lot on them. They look very good.
>
> Is the code public already ?

https://github.com/andralex/std_allocator

On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote:
> https://github.com/andralex/std_allocator

This is much more recent:

https://github.com/andralex/phobos/blob/allocator/std/allocator.d

On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
> 8. NotNull!T type
>
> For those that want a non-nullable reference type. This should be doable as a library type.

I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it.

[0]: http://forum.dlang.org/post/lcjg43$2vq1$1@digitalmars.com

On Wednesday, 9 July 2014 at 00:25:55 UTC, Meta wrote:
> On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
>> 8. NotNull!T type
>>
>> For those that want a non-nullable reference type. This should be doable as a library type.
>
> I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it.
>
> [0]: http://forum.dlang.org/post/lcjg43$2vq1$1@digitalmars.com

Also, a lot of people seem to be complaining lately (or at DConf, at least) about debugging mixins, template expansions, template constraints?, etc.

...And I was going to mention the proposed __ctfeWriteln, but it seems that it's already in Druntime. When did that happen?