[munificent]

> They are there because without variadics, there isn't a good way to do type safe text output in the style of printf.

I think an equally important point is that IO streams in C++ are extensible. You can make your own user defined types work with them. There's no way to add "printf() support" to your own type in C.

[flukus]

> I think an equally important point is that IO streams in C++ are extensible.

Not sure how portable it is but you can define conversions for your own types: http://www.gnu.org/software/libc/manual/html_node/Customizin... . The format and format_arg attributes give you compile time support: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute... .

[pjmlp]

It is just GCC C.

[flukus]

It's part of libc, so not GCC specific, it's basically native on linux and usable just about anywhere you'd want printf functionality. If the bloat (like this feature) of gnu libc are too much then I doubt the c++/d/rust equivalents will be an acceptable option. Likewise if gcc and clang (which supports printf) aren't possible then I very much doubt the platform is a compiler target for modern c++/d/rust.

[lifthrasiir]

In my opinion the most interesting aspect of iostream is the ability to inject a state to the stream: xalloc, iword and pword; they are required to make your own manipulators like `hex` or `setw`. Of course, this is to support a (questionable, again in my opinion) design of manipulators conceptually affecting the state of stream, and there are many saner alternative designs not requiring this kind of "extensibility".