My thoughts & experiences with D so far, as a novice D coder

[Jesse Phillips]

On Wednesday, 27 March 2013 at 15:34:20 UTC, Vidar Wahlberg wrote:
> I know I'm probably going to upset some people with this, 
> bashing their favourite child and all, but I wanted to let you 
> know the experience I've had with D so far, as a novice D coder 
> with a heavy Java & light C++ background.

I think D has quite a strong set of critic users, namely because 
the benefits are just too great.

Not to suggest less importance to these issues, but these are 
known issues. It is good to have them brought up from the new 
user perspective.

> Woes:
> -----
> - I find myself in a world of pain when I want to share data

I don't use this, but my understanding is that 'shared' is a low 
level feature. In general one doing threading should never touch 
it and instead a library is built from it.

The problem is we don't have a good threading library, we have 
parallelism and concurrency which may use threads but not always 
what one would expect when looking for threading.

I could be completely wrong here!

> - While the "auto"-keyword often is great, it can lead to 
> difficulties, especially when used as the return type of a 
> function, such as "auto foo() { return bar; }". Sometimes you 
> may wish to store the result of a function/method call as a 
> global variable/class member, but when the function/method 
> returns "auto" it's not apparent what the data type may be.

My observation is that many times in D the type is something you 
probably don't want to write out even if you know it. Using 
typeof() tends to be a better choice even if it isn't straight 
forward.

> Gotchas:
> --------
> - The lack of "rectangular" arrays created at runtime in D 
> ("int i = 5; int[i][i] foo;") can be quite confusing for 
> programmers with Java or C++ background.

Well in this case you are trying to create a static 2D array with 
a runtime value.

I haven't had issues with 2D arrays, but I'm not familiar with 
"rectangular" arrays.

> - Static array versus dynamic array was one of the first traps 
> I stepped on

Static arrays are very hidden. Much like arrays are hidden in C.

> - When casting a value to an enum, there's no checking that the 
> value actually is a valid enum value. Don't think I ever found 
> a solution on how to check whether the value after casting is a 
> valid enum value, it hasn't been a pressing issue.

This would be nice, but enum's are also nice for binary flags.

auto option = My.A | My.B | My.C;

option would be a valid My for how it is used, but it is not 
defined as valid. There has been discussions on alternatives to 
using an enum (but enum is convenient).

> - Compiling where DMD can't find all modules cause a rather 
> cryptic error message. A solution is to make sure you specify 
> all source files when compiling.

The compile => link process is pretty well hidden in most 
languages these days (many don't have it).

> Wishlist:
> ---------
> - "void[T]" associative array (i.e. a "set") would be nice, can 
> be achieved with "byte[0][T]".

I think a proper library container would be fine.

> - "Foo foo = new Foo();" for global variables/class members. 
> Now you must "Foo foo; static this() { foo = new Foo(); }".

This won't happen. It is kind of a feature. Otherwise you'd be 
confused with the static this dependency error because "I'm not 
using static this."