Closed danakj closed 1 year ago
Adding support for fmtlib here: https://github.com/chromium/subspace/pull/244
There is so much to re-implement for display and fmt is high quality and widely used. I think it's the right path, so adding support for formatting of each type.
I need to look further into:
Option<unknown>
can print Some(...bytes...)
There is no debug vs display differentiation in fmtlib.
We could add to parse() to look for a ?
formatting character so you could write {:?}
and get different behaviour. At the moment there's nothing that I would print differently and you don't get the distinction of a type being Debug
but not Display
. It would have to be Display
in order to maybe also be Debug
. In which case it's not worth doing anything with until we have types we want to print differently in a debug mode than in a "display" mode. But then.. those are normally types that are only Debug
and in this case they'd have to be Display and just the user would not get nice stuff from them. Unless Debug was a long multiline thing and Display was a short thing? idk I don't see it yet, we can consider using the ?
formatting character if we need it on a per-type basis or for all subspace types.
subspace/string/compat_stream.h will allow streaming of any (public) subspace type that is formattable.
For some reason the stream operator is not being picked up and used by GTest's ADL mechanisms on MSVC and it's breaking my brain. The decltype stuff for SFINAE all resolves when I reproduce it myself. Not sure if this is a blocker issue or what.
OK it was caching problems due to one TU seeing the operator<< template and one TU not, and compilers cacheing the first resulting GTest template for that type. Resolved by putting the operator<< template in prelude.h which it can do with just iosfwd.
Since we have operator<< there is no need for PrintTo.
I think https://github.com/chromium/subspace/pull/244 is sufficient to close this issue.
We need to be able to print numerics without casting them to primitives every time.
Some basic options exist:
Modeling Debug/Display traits as concepts instead we can do it differently, but something like (2) or (3) above.
This version will look up write_debug() through ADL:
It can be implemented as a friend function:
Or a free function:
This version will look for the method on the class. It can't be added types you don't control.
And the method has to clutter the type's public API, even though it should not be called directly.
I think we should go with the first option.
Then we have two more choices:
As there's much to be done for how the Formatter would work, the Formatter should not be stabilized along with numeric types, but the use of them through PrintTo() or << depending on the above, is fine.