Few things

[BCS]

bearophile wrote:
> Hello, this is my second post on digitalmars newsgroups (the first one is on digitalmars.D.learn). Here are some ideas, suggestions (and some problems too) I have found. I am currently using dmd 1.020 on Windows. Probably some of them are useless (maybe because already present, in the same or different form), or already discussed/refused, or even plain stupid, but you may find something interesting too among them.
> 

"I bid you wv'elcome" --Bela Lugos'D

> 
> 1) ...
> To compile/run you just need:
> 
> dmd importer.d
> dmd -run importer.d
> 

shouldn't that be on line: dmd importer.d -run

or am I misunderstanding?

> So the programmer can avoid giving the module names two times, once inside the code and once again to the compiler. Later I have found that the good "bud" utility does that and quite more, but I belive the compiler can have that basic capability of looking for modules by itself.
> 

> -------------------------
> 
> 5) Inside the unit tests I'd like to use something else beside the assert() like the fail():
> 

you should known what will be thrown and the function can do the assert, 
so I'd go with this

void Raises(TyExceptions)(lazy void act, lazy char[] msg) {
    try
      act();
    catch(TyException e)
      return;

    assert(false, msg());
}

Raises!(MyExp)(someFunc(), "error "~message() );

> -------------------------
> 
> 6) It can be useful a way to create an empty associative array with something like:
> new int[char[]]();
> 

assigning null to an aa results in an empty aa, I'm not sure if it clear 
other references to it though.


> -------------------------
> 
> 7) From the FAQ: >Many people have asked for a requirement that there be a break between cases in a switch statement, that C's behavior of silently falling through is the cause of many bugs. The reason D doesn't change this is for the same reason that integral promotion rules and operator precedence rules were kept the same - to make code that looks the same as in C operate the same. If it had subtly different semantics, it will cause frustratingly subtle bugs.<
> 
> I agree with both points of view. My idea: calling this statement differently (like caseof) instead of "switch" (like in Pascal), so you can change its semantics too, removing the falling through (you may use the Pascal semantic too).
> 

fall thought case is of a lot of use in generated code and a number of 
other cases. I have a templated parser that benefits tremendously from it.

> -------------------------
> 
> 14) Maybe it can be useful to optionally associate a unittest to the name of the function/class/method tested. Possible syntax:
> unittest (name) { }
> Or:
> unittest name { }
> This may be used by IDEs to manage test-driven development in a smarter way. I don't know how the compiler itself can use that information.

you can just put it in the class

class C { unittest { } }

>  
> -------------------------
> 
> 15) On windows, expecially for newbies I think it can be positive to have a single zip with all necessary to use D (with dmd, dmc, bud and maybe dfl too).

ditto for dmd + dmc, there might be some issues for including 3rd party 
aps though

> 
> -------------------------
> 
  > 17) It may be good if in dmd the -run parameter can be positioned 
anywhere in the command line.

-run is at the end because all args after it are passed to the program, 
it's used a a delimiter