An interesting consequence of safety requirements

[dsimcha]

== Quote from grauzone (none at example.net)'s article
> Andrei Alexandrescu wrote:
> Also, does anybody really care about SafeD, or would it be better if we
> had some sort of valgrind for D? Maybe this is one of those features
> which first sounded nice, but then it turned out it's better to drop them.

I'm starting to get that feeling.  It seems like D was just not meant to be a
fully safe language.  It was built from the ground up to be a better C++, i.e. a
close to the metal language that assumes the programmer knows what he/she is
doing, albeit one with enough high level features that it doesn't require
attention to the irrelevant in day-to-day programming.  Shoe-horning D (originally
designed as close-to-the-metal/programmer-knows-best) into a safe Java-like
language is going to work about as well as shoe-horning C (originally a very
low-level portable assembler) into C++ (a language that tries to be high-level but
is too hobbled by C compatibility to actually achieve it).

Example (Simple program that has no chance of working in SafeD):

import std.getopt;

void main(string[] args) {
    uint foo;
    getopt(args, "someParam", &foo);  // Not allowed in SafeD.
}

Personally, if an example like that won't even compile, I refuse to ever use SafeD
for any project I do because it is simply too rigid.  On the other hand, if it
does compile, SafeD provides no guarantees and is next to useless.