> auto main() -> int

Isn't that declaring the return type twice, once as auto and the other as int?

There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas.

https://en.cppreference.com/w/cpp/language/auto.html

auto f() -> int; // OK: f returns int

auto g() { return 0.0; } // OK since C++14: g returns double

auto h(); // OK since C++14: h’s return type will be deduced when it is defined

auto g() -> auto { return 0.0; }

But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier.

St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently.

There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?

Beer and liquor alone would blow past that figure.

If your version of hosting is "let's outsource it and just open the wallet", then, yes, sure, you can spend a lot of money. It ain't hosting, though. You failed the "what if I just replaced you with a bank account" test.

A lot of people in the space just drop the “systems” when talking about it.

I am also planning to add some PR templates so contributors include the context up front, which should make any release note generation more accurate.

Are you using any tooling to help with changelog curration? I know towncrier is all about fragments, so contributors must had write a brief summary of their contribution, which would be more in-line with your preference.

One thing I am trying to do is make the generator surface breaking/migration items explicitly, but I still think anything that requires human judgment (migration steps, caveats) should be hand-curated in a dedicated document like you suggested.

I'm thinking of reviving my Python SQL parser prototype I have half done. Or maybe resume my Mako template plugin for PyCharm.