Notes IV

[Jason House]

bearophile Wrote:

> 3) In my D code I keep writing "length" all the time (currently I can find 458 "length" words inside my d libs). It's a long word, $ inside the scope of [] helps reducing the typing, but I often enough write "lenght", so I think still a default attribute named "len" (as in Python) may be better than "length". The attribute "dup" too is an abbreviation, probably of "duplicate", so abbreviations seem acceptable in such context.

I agree that len is better than length (I like shorter code), but I agree with the other poster that size is even better.


 
> 6a) Often most of the time necessary to write programs is used to debug the code. So I encourage D to try to adopt syntax and other constructs that help avoid bugs in the first place. Many bugs can be avoided adding certain runtime cheeks that the compiler can remove when the code is compiled in release mode.

I totally agree with this.  My biggest pet peeve is accessing null variables causing crashes.  I'd love to see this give meaningful error output without needing a debugger to catch it in the act.



> 7) The D syntax of is() is powerful, but I think in some of its variants it's not much readable, so may there may be a better syntax (even if requires is() to be split in my more than one syntax).

I totally agree.  I always look this up when I use it (I just don't use it enough to remember the proper syntax)



> 10a) The new syntax for properties in C# seems nice; instead of this code:
> private int myval;
> public int Myval { get { return myval; } private set { myval = value; } }
> You just need:
> public int property Myval { get; private set; }

Seems good.  The difference between properties and true variables are rather subtle.  I worry that it's an error-prone construct.



> 14) D follows the good choice of fixing the length of all types, but real. I can accept that some compilers and CPUs can support 80-bit floating point values, while others can't, but I don't like to use "real"s leaving the compiler the choice to use 64 or 80 bit to implement them. So "real" can be renamed "real80", and have a fixed length. If the compiler/CPU doesn't allow 80 bit floating point numbers, then fine, you don't find real80 defined, and if you use them you get a syntax error (or you use a static if + an alias to rename float as real, so you can fake them by yourself. I don't like the compiler to fake them silently for me).


I've never been all that happy with the fixed size thing...  I think sizes should be compiler-dependent unless the user is explicit about what they want.  That gives the compiler room for optimization on whatever the hardware happens to be.  I'd actually like to see "int" be variable length and have stuff like int8, int16, int32, int64 have set sizes.  In my mind, it has the added benefit of making code that uses them more readable as requiring a fixed size.



> 15) I'd like to import modules only inside unittests, or just when I use the -unittest flag. With the help of a static if something simple like this may suffice:
> static if (unittest) {
>   import std.stdio;
>   unittest foo1 { ... }
>   unittest bar1 { ... }
> }

I like this too.





> 17) After using D for some time I think still that "and", "or" (and maybe "not") as in Python are more readable than "&&" and "||" (and maybe !, but this is less important).
> The only good side of keeping them in D is to make the compiler digest C-like code better.
> GCC has the -foperator-names option, that allows you to use "and", "or", etc, in C++ code.

Also sounds good.  I've been coding C++ long enough to not care about use of the weird symbols, but that's probably not helpful for people starting out with D as a language.