http://wiki.dlang.org/Vision/2015H1

Looking at this, It's obvious that some of it has spilled over, but it would be nice to have a fresh document detailing the plan moving forward.

I'm hoping to see something about D's memory model. In particular, an update on DIP74.

There are several things in phobos that are classes. This goes against the nogc goal, so what's the plan?

Currently, it seems like someone will eventually take all these classes/hierarchies and flatten them into some struct/template approach. I am not looking forward to this at all. I like polymorphism when it's appropriate.

For example, streams. I like to be able to do things like this:

Stream s1 = new MemoryStream();
Stream s2 = new File("..");
BinaryReader br;
br = new BinaryReader(s1);
br = new BinaryReader(s2);

But, given D's current nogc goal, it seems they must all be eliminated...unless DIP74 swoops in to save the day.

    Bit

On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
> Currently, it seems like someone will eventually take all these classes/hierarchies and flatten them into some struct/template approach. I am not looking forward to this at all. I like polymorphism when it's appropriate.

It's just a symptom of D classes being so difficult to use without the GC, compared to when I first picked up D to now I find myself barely *ever* using classes and just C-style(er, D-style?) polymorphism with structs, mixins, and alias this.
Bye.

On Sunday, 4 October 2015 at 20:18:25 UTC, rsw0x wrote:
> On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
>> Currently, it seems like someone will eventually take all these classes/hierarchies and flatten them into some struct/template approach. I am not looking forward to this at all. I like polymorphism when it's appropriate.
>
> It's just a symptom of D classes being so difficult to use without the GC, compared to when I first picked up D to now I find myself barely *ever* using classes and just C-style(er, D-style?) polymorphism with structs, mixins, and alias this.
> Bye.

Yeah, thats all good stuff, but for compile time. Also, it makes things that should be trivial to design 3x harder to code.

    Bit

On Sunday, 4 October 2015 at 20:18:25 UTC, rsw0x wrote:
> On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
>> Currently, it seems like someone will eventually take all these classes/hierarchies and flatten them into some struct/template approach. I am not looking forward to this at all. I like polymorphism when it's appropriate.
>
> It's just a symptom of D classes being so difficult to use without the GC, compared to when I first picked up D to now I find myself barely *ever* using classes and just C-style(er, D-style?) polymorphism with structs, mixins, and alias this.
> Bye.

You can use classes without GC _and_ with deteministic lifetime:

----
import std.stdio;

class A {
	string name;
	
	this(string name) {
		this.name = name;
	}
	
	void hello() {
		writeln("Hallo, ", this.name);
	}
}

struct Scoped(T) if (is(T == class)) {
	import core.stdc.stdlib : malloc, free;
	
	enum SIZE = __traits(classInstanceSize, T);
	
	T obj;
	
	this(Args...)(auto ref Args args) {
		void[] buffer = malloc(SIZE)[0 .. SIZE];
		buffer[] = typeid(T).init[];
		
		this.obj = cast(T) buffer.ptr;
		this.obj.__ctor(args);
	}
	
	~this() {
		destroy(this.obj);
		free(cast(void*) this.obj);
	}
	
	alias obj this;
}

auto scoped(T, Args...)(auto ref Args args) if (is(T == class)) {
	return Scoped!T(args);
}

void main() {
	auto a = scoped!A("Foo");
	a.hello();
}
----

On Sunday, 4 October 2015 at 22:10:18 UTC, Namespace wrote:
> On Sunday, 4 October 2015 at 20:18:25 UTC, rsw0x wrote:
>> On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
>>> [...]
>>
>> It's just a symptom of D classes being so difficult to use without the GC, compared to when I first picked up D to now I find myself barely *ever* using classes and just C-style(er, D-style?) polymorphism with structs, mixins, and alias this.
>> Bye.
>
> You can use classes without GC _and_ with deteministic lifetime:
>
> ----
> import std.stdio;
>
> class A {
> 	string name;
> 	
> 	this(string name) {
> 		this.name = name;
> 	}
> 	
> 	void hello() {
> 		writeln("Hallo, ", this.name);
> 	}
> }
>
> struct Scoped(T) if (is(T == class)) {
> 	import core.stdc.stdlib : malloc, free;
> 	
> 	enum SIZE = __traits(classInstanceSize, T);
> 	
> 	T obj;
> 	
> 	this(Args...)(auto ref Args args) {
> 		void[] buffer = malloc(SIZE)[0 .. SIZE];
> 		buffer[] = typeid(T).init[];
> 		
> 		this.obj = cast(T) buffer.ptr;
> 		this.obj.__ctor(args);
> 	}
> 	
> 	~this() {
> 		destroy(this.obj);
> 		free(cast(void*) this.obj);
> 	}
> 	
> 	alias obj this;
> }
>
> auto scoped(T, Args...)(auto ref Args args) if (is(T == class)) {
> 	return Scoped!T(args);
> }
>
> void main() {
> 	auto a = scoped!A("Foo");
> 	a.hello();
> }
> ----

And if I want to nest a class in a struct? or pass a class around? and still have deterministic destruction?

You can't nest a Scoped in a struct, and RefCounted doesn't work on a class.

It just shouldn't be this hard do such trivial things.

   Bit

On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
> http://wiki.dlang.org/Vision/2015H1
>
> Looking at this, It's obvious that some of it has spilled over, but it would be nice to have a fresh document detailing the plan moving forward.
>
> [...]

bump

On Sunday, 4 October 2015 at 22:10:18 UTC, Namespace wrote:
> You can use classes without GC _and_ with deteministic lifetime:
>
> ----
> import std.stdio;
>
> class A {
> 	string name;
> 	
> 	this(string name) {
> 		this.name = name;
> 	}
> 	
> 	void hello() {
> 		writeln("Hallo, ", this.name);
> 	}
> }
>
> struct Scoped(T) if (is(T == class)) {
> 	import core.stdc.stdlib : malloc, free;
> 	
> 	enum SIZE = __traits(classInstanceSize, T);
> 	
> 	T obj;
> 	
> 	this(Args...)(auto ref Args args) {
> 		void[] buffer = malloc(SIZE)[0 .. SIZE];
> 		buffer[] = typeid(T).init[];
> 		
> 		this.obj = cast(T) buffer.ptr;
> 		this.obj.__ctor(args);
> 	}
> 	
> 	~this() {
> 		destroy(this.obj);
> 		free(cast(void*) this.obj);
> 	}
> 	
> 	alias obj this;
> }
>
> auto scoped(T, Args...)(auto ref Args args) if (is(T == class)) {
> 	return Scoped!T(args);
> }
>
> void main() {
> 	auto a = scoped!A("Foo");
> 	a.hello();
> }
> ----

This can be shortened to:

import std.stdio;
import std.typecons;

class A
{
	string name;

	this(string name)
	{
		this.name = name;
	}

	void hello()
	{
		writeln("Hello, ", this.name);
	}
}

void main()
{
	auto a = scoped!A("Foo");
	a.hello();
}

On Sunday, 4 October 2015 at 22:49:59 UTC, bitwise wrote:
> And if I want to nest a class in a struct? or pass a class around? and still have deterministic destruction?
>
> You can't nest a Scoped in a struct, and RefCounted doesn't work on a class.
>
> It just shouldn't be this hard do such trivial things.
>
>    Bit

I think you can get a lot of mileage from using the following:

http://dlang.org/phobos/std_conv.html#.emplace
http://dlang.org/phobos/std_typecons.html#.scoped
http://dlang.org/phobos/std_typecons.html#.Unique

On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
> There are several things in phobos that are classes. This goes against the nogc goal, so what's the plan?

It is not the goal to eliminate GC usage entirely. It's not like we're getting rid of the GC. Rather, it's the goal to make it so that the GC is not used when it's not necessary and to minimize how much it's necessary. Some things will always require polymorphism and classes, and in at least some of those cases, that means using the GC. And features like appending to arrays or allocating closures will always require the GC. We just need to make sure that those features aren't used when they're not actually needed.

Now, Walter and Andrei have talked about adding some sort of reference counting to the language so that we can support a class hierarchy that's specifically reference-counted (exceptions in particular would be a target for that) - though that doesn't necessarily mean that they won't use the GC, just that their destruction will be deterministic. And std.allocator should make it easier to use classes without the GC. So, the situation with classes and the GC will be improving.

And not much in Phobos uses classes anyway. There are a few cases where it does and probably shouldn't (e.g. std.mmfile probably shouldn't be using class, since no polymorphism is required), but most of Phobos has used structs for ages, and a few places actually need classes to provide the functionality that it provides. The biggest GC problem in Phobos is probably how often you end up with closures being allocated for algorithms, particularly since it's invisible unless you use @nogc. And that definitely needs to be resolved. The second is probably how many functions return strings instead of lazy ranges, and work has been done on that, though there's still more to do. But classes are a very small part of Phobos.

- Jonathan M Davis

On Monday, 5 October 2015 at 17:27:30 UTC, Jonathan M Davis wrote:
> And features like appending to arrays or allocating closures will always require the GC.

Downward only closures should not always require GC. Pascal had these.