papers VS Windows Terminal

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are:

- The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045

- The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interpreted as preemptively foreclosing a Safe C++-style approach: https://github.com/cplusplus/papers/issues/2121

And yet, there is a good chance that C++ will start doing exactly this [1]. Because [2]:

> The performance impact is negligible (less that 0.5% regression) to slightly positive (that is, some code gets faster by up to 1%). The code size impact is negligible (smaller than 0.5%). Compile-time regressions are negligible. Were overheads to matter for particular coding patterns, compilers would be able to obviate most of them.

> The only significant performance/code regressions are when code has very large automatic storage duration objects. We provide an attribute to opt-out of zero-initialization of objects of automatic storage duration. We then expect that programmer can audit their code for this attribute, and ensure that the unsafe subset of C++ is used in a safe manner.

> This change was not possible 30 years ago because optimizations simply were not as good as they are today, and the costs were too high. The costs are now negligible.

[1] https://github.com/cplusplus/papers/issues/1401

[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

For whatever its worth, if we wait long enough C++ will include the equivalent of `malloc_good_size`. https://github.com/cplusplus/papers/issues/18

https://github.com/cplusplus/papers/issues/1668#issuecomment...

Looks like it did very well in St. Louis!

It is slowly making its way through the standards committee. https://github.com/cplusplus/papers/issues/43

The author has a fork of clang and gcc with some pretty impressive speedups, so I’m hopeful! https://lists.isocpp.org/sg14/2024/04/1127.php

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

Y'know, I spent a week investigating doing something similar with the Windows Terminal about 18 months ago: https://github.com/microsoft/terminal/issues/16495#issuecomm...

There's even more under the "Updates archive" expando in that post.

It was a pretty compelling prototype. But after I played with Polyglot Notebooks[1], I pretty much just abandoned that experiment. There's a _lot_ of UI that needs to be written to build a notebook-like experience. But the Polyglot notebooks took care of that by just converting the commandline backend to a jupyter kernel.

I've been writing more and more script-like experiments in those ever since. Just seems so much more natural to have a big-ol doc full of notes, that just so happens to also have play buttons to Do The Thing.

[1]: https://marketplace.visualstudio.com/items?itemName=ms-dotne...

Because sometimes you also want faster ordinary command line console.

cat-ting bigger files or even using tools generating lots of text output is painful using default conhost. New Windows Terminal is more than just terminal, it also builds updated OpenConsole. Dont even have to install the whole thing, https://github.com/microsoft/terminal/issues/1817 you can just rename OpenConsole.exe to conhost.exe and force copy into Windows\System32

This is "an entire doctoral research project in performant terminal emulation".

https://github.com/microsoft/terminal/issues/10362#issuecomm...

Fun fact: if you have Windows Terminal installed, it takes over `conhost.exe` and brings telemetry spying even to old apps which never had it before :D

https://github.com/microsoft/terminal/commit/906edf7002b8ccf...

Please fix this issue: https://github.com/microsoft/terminal/issues/16921 (or better yet, rewrite the whole thing in Rust)

Microsoft Terminal

[^1]: https://github.com/microsoft/terminal/issues/10362#issuecomm...

Some parts already have been open-sourced. For example, the console host component has been open sourced here: https://github.com/microsoft/terminal

And the FAT filesystem driver: https://github.com/microsoft/Windows-driver-samples/tree/mai...

Maybe they could consider an Apple-style approach: open source the core of the kernel and text-mode user space but leave the GUI closed.

Of course, open sourcing everything would be even better, but that might too big of a step for them. Open sourcing the non-GUI core could be a good initial step, whether or not it ends up going further.