Notes IV

[Bill Baxter]

downs wrote:
> 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). 
>>
> 
> Agreed. That abbreviation would be useful.

If it's gonna change, in my opinion it should be changed to "size".  C++ 
had it right.  "length" doesn't generalize well to non-linear 
containers.  What's the "length" of a binary tree?

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

My #1 typo is writelfn().  I don't know why but my fingers type that 
probably more often than the proper spelling.  I vote for std.stdio to 
have a writelfn alias.  :-)
kidding of course.


>> 18c) This is another silly bug, but I presume it's not common enough to justify compiler changes:
>> void main() {
>>   void foo(int x) { printf("%d\n", x); }
>>   foo((1, 2)); // prints 2
>> }
> This is not a bug; the comma expression evaluates, then discards all but the last expression.
> It's only in D for C compatibility, which is stupid if you think about it.
> Also, the existing usage of the comma expression makes it harder to implement more powerful native tuples.
> IMNSHO, the comma expression should be deprecated. :)


Well , does get some real play in for loops:

   for(i=0; i<N; i++,j++,k++) {
   }

But maybe that could be made part of the for-loop syntax rather than a 
general purpose thing.  Real tuples with a nice literal syntax would get 
used a billion times more than any comma sequencing thing.  And the 
comma could probably be replaced with some sort of macro/special 
function syntax.  Like  "progn(i++,j++,k++)" :-) [snigger]

--bb