Deprecating this(this)

[rikki cattermole]

On 01/04/2018 11:38 AM, Andrei Alexandrescu wrote:
> We need to have a simple recipe on how to define a canonical object. 
> That would include requirements such as:
> 
> * should work with mutable, const, immutable, and shared
> * the right way to define constructor(s)
> * the right way to define copying
> * the right way to define destructor(s)

We will also need to make this consistent for classes.

				***

So lets go back to the basics.

 From the primordial goo that is My Own Little Language (MOLL heavily WIP):

__userType [Identifier:name] {
	(Declaration|Definition)*
}

Is a value type, acts pretty much like struct.
Why do I not call it a struct? Because it shouldn't be used in user 
code. This exists only in mental models for D users currently.

So something like:

__userType Foo {
	int x;
	
	void __constructor(int x) {
		this.x = x;
	}

	void __postblit() {
		this.x = x+1;
	}

	void __deconstructor() {
		// free?
	}
}

Is comparable to D code of:

struct Foo {
	int x;

	this(this) {
		this.x = x + 1;
	}

	~this() {
		// free?
	}
}

So what does a class look like?

__userType Foo {
	enum __IS_CLASS = true;
	static TypeInfo_Class TypeInfo = TypeInfo_Class(...);

	static void*[][] __vtables = [
		[&TypeInfo, ...],
		[&TypeInfo, ...]
	];

	void*[] __vtable;
	void* __ptr;

	auto __cast(T)() if(T.__IS_CLASS) {
		// ...
	}
}

Why is this important? Because it shows that our current lifetime 
management strategies for ref counting with structs can be applied 
directly to classes.

					***

At this point in time, lets look at how each qualifier is perceived:

mutable: default, good, everything else is a pain
const: library code and the author doesn't want you to go touchy
immutable: in binary only, quite yucky
shared: a message from the library author and not much else

I do not believe we can continue this conversation with the above 
perceptions.

First and foremost qualifiers are there to tell other developers (and 
yourself in the future) what you intend on doing with a given bit of 
memory. Now we do need a way to express head-const. Because it allows us 
to say that we personally can't modify a bit of memory but we can call a 
method that does (from it).

Good engineering requires us to consider psychology on these issues. To 
create a single unified view of this, will be tricky I think, but well 
worth it.