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

[Dmitry Olshansky]

27-Mar-2013 19:34, Vidar Wahlberg пишет:
> 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.
> It's not that I dislike D, in fact there are tons of things I love about
> it, it's pretty much exactly what I'm looking for in a programming
> language at the moment. Yet, I encounter some frustrating issues when
> coding, often leaving me with the impression that I'm fighting the
> language more than the problem I'm trying to solve.
> True, there are many things I don't know about D, compilers or the inner
> workings of a computer, and some of the fights I have with the language
> are likely started by myself because I'm dragging along my bias from
> other languages, drawing misconceptions on how the D language actually
> works.
> My intentions are not to insult, but shed some light on some of the
> difficulties I've faced (and how I solved them), with the hope that it
> will help others from facing the same difficulties.
>
>
> Woes:
> -----
> - 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.
>
> - 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).

Currently documentation for match states in plain text that:
" ...
Returns:
a RegexMatch object holding engine state after first match.
"
Where RegexMatch is a template to be found in the the same module. I can 
see that docs are nothing stellar but the key info is present.

That being said I see no problem with ReturnType!xyz, typeof(smth) or 
just typing auto.

> This was all but obvious to a novice D coder as myself, the solution was
> suggested to me in the IRC channel.
>
>
> 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.

The code you suggested doesn't work in both C and Java.

> Even though there exists alternatives
> (http://denis-sh.github.com/phobos-additions/unstd.multidimensionalarray.html),
> this design decision and how to get around it when you really desire a
> "rectangular" array could be explained in more detail at
> http://dlang.org/arrays.html.
>

IRC you can get jagged arrays with the syntax:
int[][] arr = new int[][](x,y);


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

Linker... there are many ways to improve on that old technology that but 
not much have been done. And the problem is not D specific.

There is a tool rdmd that tracks all dependencies:

rdmd main_module.d

That plus:
rdmd --build-only main_module.d

Is more then enough in 90% of cases for me.

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

We need a better set anyway as hash-map is a good map but suboptimal as 
a set.


-- 
Dmitry Olshansky