Cleanup and improve std.format

[9rnsr]

Points:

• Cleanup template specializations for more maintainable.

• Add toString(sink) support.

  It is useful when format specifier does not need.

• Add format specifier %| for nested range formatting

  Previously, In %( xxx %s yyy %) yyy is interpreted as separator implicitly.
  But this rule is not good for nested range formatting.
  e.g. {%(<%(%d%)>, %)} with [[1,2,3], [4,5,6]] makes {<123>, <456}.

  New %| format specifiers explicitly divide format strings for element and for separator.
  It is used only inside %( and %)
  e.g. {%(<%(%d%)>%|, %)} with [[1,2,3], [4,5,6]] makes {<123>, <456>}.

• Add '%c" specifier for character type formatting

  It is already supported for unformatting.
  And also, it is necessary for nested range formatting. Now, inside compound format specifier, %s runs proper element formatting (do escape for strings, characters, and ranges). It is useful, but in some cases we need a way to avoid escaping. %c just do it for characters.

• Issue 5354 - formatValue: range templates introduce 3 bugs related to class & struct cases

  Check toString is overridden in runtime for class input range object.

• Add toString(sink, ...) support for class and interface types

• Add tests and improvements for reflective formatting.

  'Reflective' means:

  1. format value.
  2. unformat formatted string with same specifier.
  3. the result value equals to original

  And now, reflective formatting is CTFEable, except floating point formatting.

[9rnsr]

Make reflective formattings CTFEable. Thanks for Don's fixing dmd!

[9rnsr]

OK, now we can test this pull without any compiler fixes.

[andralex]

I'm not very fond of "%|", it adds complication. But I guess there's no way without it or something like it. The problem is there's no way to specify a terminator, for example you can't format the array [1, 2, 3] as "1;2;3;" and the empty array as "". If you force adding a terminator after the format specifier a la "%(%s;%);", then the empty array is represented as ";". Yuk. Any ideas for a simpler approach?

[9rnsr]

The problem is there's no way to specify a terminator, for example you can't format the array [1, 2, 3] as "1;2;3;" and the empty array as "".

You can use "%(%s;%|%)". It has explicit terminator ;, and empty separator.

[braddr]

Looks like this has bit rotten a little.. merge conflicts.

What's left to get this pull committed? It's been open a good while.

[9rnsr]

Updated.

[braddr]

Now fails due to some delegate related issues, likely due to recent changes..

[9rnsr]

I've already posted #593 for more escape check.

[jmdavis]

Why aren't these enums immutable? const buys us nothing here as far as I can tell. e.g.

enum immutable Char[] seqAfter = "]";

Shouldn't all of these variables that you just changed from static to enum be changed to be immutable like that?

[9rnsr]

The thing I had thought is "Change formatting with global state is less useful. They should be only default values for sequence formating". So I had converted them to manifest constant simply.
Therefore, I can agree to change const to immutable. But

enum immutable Char[] seqAfter = "]";

causes "conflicting storage class immutable" error. So I'll change them to

enum immutable(Char)[] seqAfter = "]";

like string type.

[jmdavis]

If fully immutable doesn't work, that's fine, though with the recent changes to IFTI, it's generally less of a problem than it was. It doesn't really matter in this case though. You end up with a new copy of the enum every time you use it anyway. It's being const instead of immutable that's the real issue.

[9rnsr]

It's being const instead of immutable that's the real issue.

?? These manifest constants are dynamic array, and the compiler stores the content of string literal at most once into exe file.
So, yes, manifest constant creates a copy in each place that used, but it is 8 byte structure (in 32 bit system), not full copy of string.

I think the change from const(Char)[] to immutable(Char)[]` is better, because it expresses the elements never modified.
But it is not real issue.

[jmdavis]

Why bother with the return; when it's already at the end of the function?

[9rnsr]

No, there is not at the end of the function. The return statement is need.

[jmdavis]

There are a lot of calls to enforce in std.format which don't use FormatException (though not all). Is there a reason for this? Normally, I would expect code in Phobos to throw an exception related to its module (and possibly one more specific to the error that it's reporting), not `Exception." It's too generic.

[9rnsr]

As I wrote in above comment, I don't like enforceEx because the condition that's the most important part does not stand out. But also, I can agree enforce is too generic than enforceEx and using it is better.

I had thought to define alias enforceEx!SomeException XXX, but it was impossible...

[jmdavis]

alias enforce!SomeException is not enough to instantiate the template. The first argument is templated is well.

[9rnsr]

Applied review result.

[andralex]

Jonathan, since you spent time getting into this diff, you may want to merge it when ready.

[jmdavis]

Merged.

[9rnsr]

Thanks for your reviewing and merging, @jmdavis!

[CyberShadow]

This pull request introduced a regression:
https://d.puremagic.com/issues/show_bug.cgi?id=12505