Sorry for the delayed answer. Andrei Alexandrescu:
>In wake of printing multi-dimensional arrays, I agree that start and end >delimiters should be present by default. If delimiters are present, it only >makes sense to make the array look like a D array, so the ", " becomes an >acceptable proposition.< Good :-) >I wonder whether that's a desirable behavior.< I like it this way (but str2 is "[\"hello world\"]", as Steven Schveighoffer says), because my programming experience has taught me that explicit is better than implicit (also as said by Python Zen), and quotation marks make the output a little more unambigous. It's a matter of balance between being fully unambigous (useful for people, but also for the computer) and being nice and readable (useful for people). It's how I have designed the put/putr functions in my dlibs, the function they both use take an extra boolean argument named "repr", that tells apart the repr/str cases. When called inside a collection then repr=true, and it's true for all successive nested recursive calls. And ["hello world"] is you write such array in normal D code, so you can perform a copy & paste from one outout into a D source code, this is a very common thing done in Python, and it's the base for the doctest module: http://docs.python.org/library/doctest.html Extra note: Python avoids many of those \ using a bit smarter quotation strategy, that involves four different symbols: " """ ' ''' While D spares the need of the """ ''' because D strings are multi line, and D uses '' to represent char literals. D1 has naked escaped char literals too but they were not appreciated much. >Currently that's the general plan, but I wonder whether we should change the >approach.< If you or someone else shows some alternative possibilities we can discuss what is the better one. ---------------- Steven Schveighoffer: >I like that, it shows consistency. If you want to change the format, you can >via to's parameters. But the most useful defaults should be the same in >writeln.< sensible defults can help a *lot* the programmers/users. ---------------- Fawzi Mohamed: >I think that that design is very efficient and clean, well I have to admit that I *hate* toString and methods that convert stuff to string, because they are unnecessarily inefficent.< In many cases in my code toString is used for small/medium outputs in debug mode, so performance is not so important. Computers can today generate even MB of strings in a short time. But if you want more performance, then the built-in object/struct toString may take an optional argument (that defaults to null, that means the behavour currently used), that is the sink you talk about. If you like this simple idea (that is backwards compatible if you don't add such sink arguments) you can talk about this in the main D newsgroup. Bye and thank you very much Andrei for changing your mind a little, bearophile
