An interesting consequence of safety requirements

[Andrei Alexandrescu]

dsimcha wrote:
> == 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.

getopt takes pointers just because variadic references aren't available. 
It's not a matter of principles. I agree that a useful module such as 
getopt should work in safe mode.

Andrei