Few things

[Sean Kelly]

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.
> 
> 
> 1) This is quite important for me: dmd may look for the needed modules by itself, starting from the current directory and package directories (the -I parameter is useful still for more complex situations), and the exploring the directories in the "path" variable. So instead of:
> 
> dmd importer.d amodule1.d amodule2.d ...
> 
> To compile/run you just need:
> 
> dmd importer.d
> dmd -run importer.d
> 
> 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.

This has been requested before and I think it would be a useful feature 
to have.  Build tools like Bud could still add value by supporting 
custom build scripts, packaging, etc.

> -------------------------
> 
> 2) dmd can start looking for the files read by the "import expressions" from the current directory (where the main module is), so in most situations the -J flag isn't necessary anymore.

I think the -J flag was added for security purposes so the import 
feature couldn't be subverted.  But I agree that it's not useful to the 
average programmer.

> -------------------------
> 
> 3) I think it may be better to import "statically" by default (as in python, in that language people suggest to avoid the "from amodule import *" that means import all names from amodule).

I think private import by default is enough, though the symbol lookup 
rules complicate things somewhat for library design.  It would be 
preferable if private symbols weren't visible to other modules.

> -------------------------
> 
> 4) Python defines < <= == != >= > among dicts (AAs) too:
> 
>>>> {1:2, 2:3} == {1:2, 2:3}
> True
>>>> {1:3, 2:3} == {1:2, 2:3}
> False
>>>> {1:2, 2:3} < {1:2, 2:3}
> False
>>>> {1:2, 2:3} > {1:2, 2:3}
> False
>>>> {1:2, 2:3, 3:1} > {1:2, 2:3}
> True
>>>> {1:2, 2:3, 3:1} > {1:2, 2:3, 4:1}
> False
>>>> {1:2, 2:3, 3:1} < {1:2, 2:3, 4:1}
> True
> 
> It seems not even the quite useful opEquals among AAs is defined yet in dmd V1.015:
> assert(['a':2, 'b':3] == ['a':2, 'b':3]);

Seems handy, and more consistent than the current behavior.

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

You can do this with Tango if you define a custom unit tester.

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

What is the use for this over initializing to null?

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

It's a good idea, but I actually like the fall-through behavior.  I use 
it regularly.

> -------------------------
> 
> 9) Often 90% of the lines of a program don't need to run at max speed or to use as little memory as possible, for such lines a higher-level kind of programming is the best thing. For the other 10% of lines, D allows a lower-level programming style, allowing assembly too.
> For that 90% of code it may be useful to add an *optional* parameter to the sort property/methods of arrays, you may call it 'key' (see the same parameter of Python V.2.4+ sort/sorted), it's a comparison function that takes a value of the array and return another value that is compared to sort the original values.
> (Note: CPython has a *really* optimized C sort routine, called Timsort (inside listobject), D may just copy it if some tests show it's faster & better). (There is an almost-free-standing version of Timsort too that can be found online.)

I'm not sure if this solves the same problem, but Tango offers a sort 
routine that takes a predicate.  It can be called as myArray.sort(&cmp) 
in most cases, making it look much like a built-in feature.

> -------------------------
> 
> 10) I think few useful properties/methods can be added to the built-in AAs:
> - aa.clear() to remove all key/val from the AA.
> - aa.dup, to create a copy of the AA.
> - aa.sort, that compulsively takes a 'key' function (that takes two arguments, key and value) and returns the sorted array of the keys. Here is a simple example of such sorting:

All sound useful, though it may be confusing to have AA.sort behave 
differently than array sort.

> -------------------------
> 
> 12) From the docs:>Pointers in D can be broadly divided into two categories: those that point to garbage collected memory, and those that do not.<
> GC pointers don't support some operations, so why not define two kinds of pointers (gcpointer?), so the compiler can raise an error when the code tries to do one of the many illegal operations (= that produces undefined behavior) on GC pointers? (If it's needed a cast() may be used to convert a GC pointer to a normal pointer and vice versa).

I'm not sure I understand.  Could you explain this further?


Sean