Interesting write up. It should be part of their documentation, it's helpful to have historical contextual info like this.

for functions that don't escape the current compilation unit (`static` functions, anonymous namespace functions), can/do compilers ignore calling conventions and do the faster thing? Of course, they can just inline, and that makes this moot.

Oh yeah, re: SQL expect - I always wish joins had a "cardinality assertion", like a regex *?+ (or ! for exactly one)

Fell for the Crosstrek but then got the ick with that dash tablet

That is the idea of C++ profiles, based on Ada's language profiles, being pushed by Bjarne Stroustoup.

Now, how willing WG21 and the compiler vendors are open to the idea, is anyone's guess.

I'd add less verbose ranges. Idk about memory safety, optional and expected are working pretty well for me (i just use it on personal projects though)

You can't possibly put syntactic sugar on the same level as memory safety.

I'd also vote for std::string split and join functions. And networking.

Qt?

Lol “only”

What’s the use case for static reflection?

Just don't write bugs!

It's impossible to memory leak even with bugs if you don't use antique parts of the language that won't pass any static analysis anyways.

Considering that Chromium, being one of the most heavily statically analyzed code bases, is full of commits which fix memory leaks, your comment makes absolutely no sense.

https://github.com/search?q=repo%3Achromium%2Fchromium+memor...

Chromium is a massive project spanning decades of intense active development that intricately connects just about every domain of programming.

A few leaks fixed per month is nothing. Further there is no major language promising no leaks once you include things like retained references to garbage and reference cycles. Leaks are one thing modern C++ solves pretty well.

Anything written by Google is absolute bottom of the barrel shit.

It's not indicative of anything average in the real world.

It's a bit hard to get an overview. But I did spot several uses of owning raw pointers and switching from those to managed ones. I'd say that's exactly the point I was trying to make.

What antique part of the language am I using in this bugged code?

    class A {};
    std::unique_ptr<A> array(new A[256]);

It's very easy to produce innocuous-looking code that contains leaks. (And yes, I know that make_unique solves the problem here.)

At this point I'd rather just write assembly language.

new

Love me some lateral join / cross apply. Correlated subqueries and visibility in the where clause?! Whoo.

The backtrace argument is good, but I wonder how valuable traces would be in a world that never experienced reads-of-nothing (npe, reading from undefined, reading out of bounds array, etc). Presumably this would be because of 100% use of ADTs, or maybe some other mechanism; but, even Haskell throws exceptions out of `IO a` so such a world might never be realized.

This is a problem, seems like ctes and views are a possible ormless solution here

CTEs and views are both a bit bigger than the parts that you would normally want to share and reuse, and they're also not very well standardised. Plus no-one really agrees on how dynamic tables should be, so you end up with the Excel maintainability problem of no real separation between code and data.

Thanks man I really feel the same when what should be 2 joins, becomes an all day hellscape of inspecting orm emitted sql, to debug why its blizzard of exists-subqueries is absolutley jacked and why fixing that breaks other code depending on such bugs

Often we just want "totally adhoc result set, but constrained using some common where or join." We keep on with the orm, but it's basically a slow and complicated form of a view at this point