Another Phobos2 test

[Adam Ruppe]

bearophile:
> This kind of indentations is interesting:

I'm still trying to find something I like for this. Currently,
I see the contracts as part of the public interface, just like
the name, so I'm indenting them like I would if the argument list
ran too long.

void doSomethingBig(
      int arg1,
      int arg2)
{

}

(Sometimes I put the { on the same line as the ) but then I often
find it hard to see the difference between the arguments and local
variables.)

So, similarly, the in and out get indented. It would be messy to
shove them all on one line, but without the indent, it'd look
like it's all part of the body.

>  In such Python/D scripts I don't write stuff like this:
> [snip toString ]

One practical reason for such separation is this (seen in Python
but D does it too):

  >>> s = [1,2,3]
  >>> print s[34], s[44]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  IndexError: list index out of range


Error messages give a line number... but if there's still several
points of similar failure on that one line, it doesn't help as much
as it could.

This leads me to write things like this sometimes too:

    auto author =
      stuff["data"]
      [0]
      ["from"]
      ["name"];


So if the data isn't what I expected, the line number in the error
message tells exactly what was missing. (This is also a good
example of why semicolons are a gift from God)

>>> s = ((1,2), (3,4), (5,6))
>>> print s[1]
(3, 4)


Ahhh, I wanted a child of it!

Now, I'm forced to do it on one monster line...

>>> print s[1][3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: tuple index out of range

Gah, which one? I guess I'll use a temp variable...



Anyway, sometimes this can be fixed in the runtime by including
the data and the index as part of the exception, but not always
(what if you did [0][0]?). Putting them on separate lines is
an easy, reliably way to get more information out of the error.


> I know, but I was suggesting something different, to turn the JSON
> creation into some kind of Phobos library that you may call at
> compile-time from normal D code. Then a compile-time JSON reader in
> Phobos will allow to perform certain kinds of static introspection,
> that later will be quite useful to create user-defined @annotations.

We could do that today with a combination of -X, -J, and a CTFE
JSON parser (it's possible that std.json would work today. I haven't
tried it specifically, but ctfe tends to surprise me with its
capabilities).

Of course, you'd have to run the compiler twice, but there's other
advantages to that too (like getting dependencies - my build tool
does this - and the first run is fast anyway.


I'm tempted to do it now just to prove we can... but I'm already
a bit loaded with stuff to do.


> With "new Tuple!()()" you need to manually specify the types of all
> the fields, while "tuple()" spares this need, but allocates on the
> stack. A newTuple() function allows to do both, but I don't know
> how much often it is needed.

Maybe a generic toHeap!(T) function would be good for this. It
takes an existing object and copies it to the heap if necessary.

return toHeap!(tuple(1, 2, 3));


However, it seems to me that most tuples are likely to be small
value types anyway. You had an int, char[]. When I use tuples, they
are usually small collections of ints and strings too.

Value types don't really need to be on the heap. You can just
return them and pass them to functions normally and it works fine.


> What I'd like is a way to tell the type system that I am creating a
> sequence of 8-bit chars, and not a string of chars.

Maybe try ubyte[]?

> I know, but programming life is not orthogonal :-)

That's part of the reason I said it... I'm only half serious.

Though, on the other hand, I've used the ncurses library which does
this kind of thing. The number of function names is obscene, and
the benefit is quite small. I'm not convinced the parentheses are
a big deal. (Hell, I've done lisp before... and kinda liked it. :P)


> I think to!int('1') == 1 is useful, but I am not sure if C-derived
> programmers accept/like to!int to work differtly from cast(int) in
> this case.

The way I see it is if you are working with single chars, it is
probably because you want to do some work with the char itself -
it's numeric value. Thus it fits the same general area as int.

Perhaps you want to just work with one length strings? str[0..1]
instead of str[0].