Article about problems & suggestions for D 2.0

[Stephan Soller]

On 27.08.2011 19:16, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and
> having completed 3 projects with it, I wrote a small article about the
> problems I had with the D 2.0 programming language and what suggestions
> I have to improve it.
>
> http://3d.benjamin-thaut.de/?p=18
>
> Comments and criticism welcome

As for point no. 3 (Structs not having identity):

Structs have a postblit constructor. These have access to the new struct 
but not the old one. Maybe you can use this to register a new reference. 
If I remember this right the old reference should be cleaned up 
(unregistered) by the destructor but I'm not sure. You article implies 
that the destructor is not called for every copy of the struct.


Point no. 5, "Shared":

I actually had pretty much the same trouble with the syntax for shared 
delegates. The compiler output is very misleading. In the end this 
syntax mostly worked:

   shared(void delegate(const char[])) message_handler;

Still had to cast away the shared on the rhs expression of an assigment. 
Maybe the full code can shed some light on this:

	// An array of message handlers
	private shared( shared(void delegate(const char[]))[] ) message_handlers;
	
	// Function to register new handlers
	public shared void hook(shared(void function(const char[])) 
message_handler){
		typeof(message_handlers[0]) handler_dg;
		handler_dg.funcptr = cast(void function(const const(char[]))) 
message_handler;
		synchronized(mutex)
			message_handlers ~= handler_dg;
	}

The typeof trick to define the handler_dg variable is there because 
nothing else seemed to work.

I worked with Benjamin on the space shooter game. The above code is 
actually from the logger of that project (base/logger.d).


Point no. 7, "Associative array invariance":

This was my most frequent identifiable bug source. Pretty much what 
Benjamin said: it's annoying the program just crashes. However bugs like 
that are easy to find with a debugger... usually.


Point no. 8, "No function overloading with template parameters":

Got the same problem while templating some functions of an overload set. 
It's not possible to mix overloads with templates. That wasn't much of a 
problem but converting everything to templates doesn't work ether. In 
the end I used templates that generate normal function overloads and 
explicitly instantiated those templates.


Happy programming
Stephan Soller