This isn't something like threading or filesystem access where we need to put it in the standard library because it abstracts platform differences. This isn't something like std::unordered_map or std::sort where it's so universally useful that we want to put it in the standard library. No, this is extra functionality that should be in a third-party library.
Honestly, it worries me a little bit that such a prominent member of the C++ committee came up with such an ill-advised proposal, and it makes me worry that the success of C++11 has gone to their heads. What I don't understand is why someone would even be unhappy that this is not part of the standard library, since this kind of stuff has been available in third-party libraries for years. You shouldn't be clamoring for inclusion in the C++ standard, you should be calling for better third-party library support in your tooling!
Besides, there are parts of even the current standard that are broken enough to demand some replacements and deprecations. For example, "std::string" and "std::iostream" are pretty awkwardly implemented and it would be really nice to have something better.
This. Honestly after C++11 the stuff they're adding is scarcely useful, it mostly just complicates the language itself even more than it currently is. They're trying to change the way you write C++ code without removing support for the old ways. I feel like they should make a new language instead of adding mostly useless things/stuff that barely anybody will use (could be also because barely anybody will know of that feature's existance)
That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.
I think that graphics would be a great addition to the standard library. However, it will be tremendously difficult to create a good API that is simple to use for simple cases, yet doesn't limit one to the simple cases, and is flexible enough to fit a wide range of devices and OSes with their favorite graphics libraries.
Web developers want all browsers to support CSS, canvas and SVG, so that their applications port easily between platforms.
Why wouldn't C++ developers get it as easy?
First thing to spend a lot of time on would be what one means with 'graphics'. 2D? 3D? Static or also animated? Windowing system included?
I would go for 2D, static, no windowing system, certainly in the first version. That already could be very useful. Imagine having a standardized way to query what bitmap graphics formats the OS supports, and to easily read and write them.
Also imagine writing a plotting package on top of such a library. Porting it between various OSes would be way simpler than it is now.
But as I said: designing this will be very difficult.
YMMV, depending on your field, of course.
I've also wondered why so many random number generators and math libraries are being standardized. Maybe there's a good reason for them to be in the standard, but I haven't heard one yet.
It's in c++'s best interest to have some components whose purpose is to make things easier, especially for newcomers. io2d fills a huge gap there, one that hasn't been filled by any compilers/IDEs in a cross-platform and straightforward way. However, I agree that better c++ package management would have solved this problem, and also eliminated the need for <filesystem> etc.
I'm not happy with the specifics of the io2d proposal (50+ colour constants?) but it's a start.
We know from experience that this is a bad idea, and a waste of everyones time.
Build your application layer logic onto of a robust module ecosystem, don't try to bake it into the standard library.
...but even if you were to say, want to do this, this is a horrible legacy api before it even exists!
Hard coded color constants? (antique_white? alice_blue? Are you kidding me?)
Font support, including (presumably) true type font parsing?
Brushes and gradients?
No mention in the whole document are programmable graphics pipeline? (ie. shaders)
No mention of device independent output scaling?
Maybe we can just fork inkscape and put it into the standard library?
I know this sounds harsh, but have the authors of this proposal actually built anything using a 2D graphics api recently?
This is a high level 2D vector graphics day dream.
Nowadays, I would never suggest somebody at the level I was at then to pick up C++. It's a different world now than it was then.
But I guess if C++ realizes that, other languages may follow.
Doing cross-platform graphics well is hard. And the landscape changes pretty rapidly. Take a look at PHIGS, for instance. It's a standard . . . and it really sucks.
There's a bunch of common ground at the math level (matrix transforms, quaternions, etc.) and probably some data structures, but actually doing rendering? Whatever you cook up is likely to be a quaint, procrustean bed within five years.
Setting up a Linux desktop system is notoriously hard, at least if you are not a "computer expert". Configuring hardware that is considered mainstream among Linux professionals most of the times works out of the box. For other hardware too often CLI tools are needed. I would think that these tools often have no graphical interface because there is no standard way to program GUIs in UNIX C.
However, HTML5 seems to become the defacto cross-platform graphics standard that seems to takeover many GUI app writing tasks. It's also a good example of a standard that is actually low performance often using outdated methods. WebGL is OpenGL ES 2, DOM is so slow that people wrote React, CSS is actually designed for documents...
But I still stick to SDL for rendering mostly because it works everywhere (especially in JS with emscripten).
About pixel manipulation and image processing, VTK (from the companing doing cmake) is my favorite choice:
I think C++ won't have an standart 2D API before reflection :-)
/me hopes for image loading/saving unlike this post suggests, since most libraries are utter garbage for this