bearophile: > I understand. But splitting lines too much make the code a bit > too much thin.
I like it being thin so for me, it's a win/win. I use small and split windows as well as 8 character tab stops. (4 characters just blend into the background..) > I think a better solution is this request (from Lewis): > http://d.puremagic.com/issues/show_bug.cgi?id=5521 That wouldn't help with runtime errors... and I don't think it would help much for compile either, as a general rule. Something like "cannot call function foo() with args abc" puts you in the right place anyway, even on a pretty complex line. > Currently the JSON data is not computed at compile-time, and it's > written as file text on the disk, while a library is meant to not > touch the disk. So the situation isn't good enough yet. dmd -X -Xf- file.d That dumps it to stdout, which you can pipe out to where it needs to be. Though, getting it into the program being compiled might be a little tricky without touching the disk. But then again, does it really matter? The compile process writes files as part of its normal operation anyway. > An ubyte[] is a workaround for a type system not good enough yet. I wouldn't say that it isn't good enough. It's just that you and Andrei have a different philosophy about this. > Reducing syntax noise in functional-style code is something that > a lot of people wants (me too). Remember, one man's noise is another's parsing anchors. For example, I find an if without parens to just look... naked.