@vitaut
need to share with my wife who is an expert knitter
better software -- German in Switzerland -- leukemia survivor
@vitaut that is a sign of getting old. I started programming with orange/green on black and went "light" once I got a VGA screen. never to turn back to the dark side. with age related far sightness getting a bit more focus from a narrower aperture of your eye due to a brighter screen is the way.
@vitaut @ljs
age and backward compatibility to previous standards as well as ABI stability are the drivers for std lib implementations. wait until fmt is 30 years old and needs to support 9 different C++ standard versions
@vitaut
I hope you have more than one idea, otherwise it might end badly.
fwiw, for my C++26 version of my unit testing framework, i implemented generic output (to_string) for types not supported by format. unfortunately cannot do it directly as formatter (may be just my fault)
https://github.com/PeterSommerlad/CUTE/blob/master/ws_cute/crut/src/crutmodule.cpp
@vitaut
really:
fmt::print("{}{}",char8_t{65},'I');
@vitaut
may i recommend crashing or privilege escalation or just printing invalid unicode on specific NaNs?
@vitaut
sounds like Dijkstra and/or Hoare iirc
@vitaut fwiw, i implemented "formatting" for std::byte (unofficial) in my C++26 testing library's to_string
@vitaut
ship it for inclusion into libstdc++?
I learned much about type systems from Benjamin Pierce book(s) and from my students who i made reading and talking about them in a seminar
eg
then you have to constexprfy it and provide it for all major compiler's libs to become immortal.
i try to minimize my dependencies, however, switched to std::format recently. is that allowed?
constexpr?
@vitaut what about constexprness?