Vidar Wahlberg:
- 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.
Beside using returnType as suggested, another solution is to add
in your code something like this:
pragma(msg, typeof(foo));
This tells you the type to use for your class member.
Haskell solves this in a better way, using "Type holes":
http://www.haskell.org/haskellwiki/GHC/TypeHoles
The idea of those holes was developed in several complex ways,
but at its smallest it is just a way offered by the compiler to
the Haskell programmer to leave one thing explicitly not
specified. The program will not compile, but the error message
will tell you very well the type of what's missing. So you use
this type information to put in the hole what the compiler wants.
That static arrays are value types while dynamic arrays are
reference types may not be obvious for those with primarily
Java background.
Java has a semantics more limited compared to a system language
as D/Rust. This is not easy to avoid. On the other hand iterating
on an array of structs/fixed size arrays has a trap that a D lint
should warn against.
- 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.
cast() is a sharp unsafe tool. In Bugzilla I have a request to
use to!() to perform that safely.
- Compiling where DMD can't find all modules cause a rather
cryptic error message.
This was improved, and maybe there is further space for
improvements. It's a fixable problem.
Wishlist:
---------
- "void[T]" associative array (i.e. a "set") would be nice, can
be achieved with "byte[0][T]".
I think there's no need to add that as a built-in. There are
things much more important to have as builtins (like tuples). For
that a Phobos Set!T suffices.
- "Foo foo = new Foo();" for global variables/class members.
Maybe in some time it will happen, thanks to Don too.
Bye,
bearophile
