We have already accomplished a great deal. Compile-time C++ is already fully free of UB, which means a huge chunk of real-world C++ is already UB-free today.

This statement is so categorically ridiculous that I have no choice but to assume that Herb Sutter is deliberately trying to mislead people. I would be very surprised if even 5% of “real-world C++” occurred at compile time. In fact, I would be very surprised if even 5% of “real-world C++” was valid constexpr that just ran at runtime.

I was more thinking along the lines of having FOSS repos that are primarily used by me but which can accept external pull requests by anybody with a Github account.

I like the idea of running my own machine for CI but I don’t like the idea of having to become knowledgeable about avoiding exploits.

Just self host an open source runner like woodpecker and you’ll never have to move again

How painful is the setup and general maintenance/security?

I’m considering the idea but I just don’t want to deal with people abusing exploits in the actions that give them access to my LAN.

According to this this slideshow:

At a fundamental level, this is the state of terminal emulators today as I saw it. You have fast terminals, feature rich terminals, and native terminals. You can pick at most two properties to have.

Ghostty aims for – and in my opinion already achieves – all properties.

Also, calling out the warning signs, my bar for a native platform experience is that the app feels and acts like a purpose-built native app. I don’t think this bar is unreasonable. For example, I don’t think it’s unreasonable to say that Alacritty is kind of not native because new windows create new processes. Or that Kitty is kind of not native because tabs use a non-native widget. And so on (there are many more examples for each).

Take a look at xtask. It essentially relies on the fact that you can add cargo aliases in local files in order to execute specific packages.

When I create a workspace that has some form of code generation I like to overwrite cargo gen to whatever is doing the generating.

Number 4 is only about not returning impl Into and instead just returning T.

That’s a bummer. I guess what I though was PyO3 type hints was actually just PyCharm guessing at the types.

I tried creating a .pyi file and it seems to be a pretty big improvement over no type hints, but I don’t know how to add type hints for modules added with PyModule::add_module and adding the .pyi file seems to make the type checker not know about my other modules.

Would you mind sharing the script for auto generating type hints? Keeping them in sync manually would be pretty annoying.

How is the quality of the generated bindings?

I have previously used PyO3 for Python bindings and it doesn’t seem to correctly generate type hints.