Adam Ruppe: > I'm still trying to find something I like for this.
Me too. > 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. I understand. But splitting lines too much make the code a bit too much thin. I think a better solution is this request (from Lewis): http://d.puremagic.com/issues/show_bug.cgi?id=5521 > 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). 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. > Maybe try ubyte[]? There are moments when I want an array of ubytes, other moments when I want an array of 8 bit chars, and other situations where I want a string of chars. An ubyte[] is a workaround for a type system not good enough yet. > 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 agree that too many functions are going to give problems. But an "a" suffix is burden smaller than two names fully new. > I'm not convinced the parentheses are > a big deal. (Hell, I've done lisp before... and kinda liked it. :P) Scala, Ruby, ML-class languages like Haskell, etc have means to reduce parentheses count. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). I have used Scheme, but parentheses tire me after a while. > Perhaps you want to just work with one length strings? str[0..1] > instead of str[0]. I have done this some times. I presume I will need to use this more. Bye and thank you, bearophile