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

[Dicebot]

Welcome and thanks for sharing your experience! Few (hopefully) 
useful hints:

> -----
> - I find myself in a world of pain when I want to share data 
> more complex than the basic data types (int, char, byte, etc) 
> across threads. Seemingly the magic trick is to "cast(shared) 
> foo" (or "cast(immutable)") when passing objects/references to 
> another thread, then "cast(Foo)" back on the receiving end (as 
> most classes/structs in the standard library refuse to let you 
> call any methods when the object is shared). The examples in 
> the source and TDPL are fairly limited on the issue, it mostly 
> covers only those basic data types.

That is somewhat intended as D proposes message-passing a 
"default" multi-threading approach and makes sharing global data 
intentionally difficult. What lacks though, is some solid article 
series about how "D way" of doing things here, it is often quite 
not obvious. Definitely an area for improvement.

>
> - 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. 
> While you may be able to find out what "bar" is by digging in 
> the source code, it can still be difficult to find. One example 
> is to save the result of "std.regex.match()" as a member in a 
> class. For me the solution was to "import std.traits", create a 
> function "auto matchText(string text) { return match(text, 
> myRegex); }" and define the class member as 
> "ReturnType!matchText matchResult;" (do also note that function 
> & member must come in the right order for this to compile). 
> This was all but obvious to a novice D coder as myself, the 
> solution was suggested to me in the IRC channel.

It is much more simple actually, "typeof(match(string.init, 
Regex.init)) variable;" and no extra functions or source digging 
is needed. D static introspection is so much more powerful than 
in other languages that is often completely overlooked by 
newcomers.

> - Static array versus dynamic array was one of the first traps 
> I stepped on 
> (http://forum.dlang.org/thread/jnu1an$rjr$1@digitalmars.com). 
> Until Jonathan M. Davis explained it in detail 
> (http://d.puremagic.com/issues/show_bug.cgi?id=8026#c4), I 
> pretty much considered it as "magic" that 
> "randomShuffle(staticArray);" did not sort the array while 
> "randomShuffle(staticArray[]);" did (the first call now gives 
> you an compile error, though). That static arrays are value 
> types while dynamic arrays are reference types may not be 
> obvious for those with primarily Java background.

Unfortunately, there is a conflict of interest when targeting 
both programmers with Java and C background at the same time, 
what D tries to do. Sometimes it is very hard to resolve right.

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

You most likely want std.conv.to - Phobos lexical cast. It does 
check enum valid values.

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

Have you tried rdmd?