array-like storage with dynamic size has existed since forever - it's vector. over or undercommitting is a solved problem

VLA is the way to bring that into type system, so that it can be it's own variable or struct member, with compiler auto-magic-ing size reading to access members after it

vendor: "we present 100% electric car"

we: "that's cool, I always wanted to decrease petrol use. But... can you provide an option for some petrol use? It's called hybrid, iirc?"

vendor: "no, our requirements only support 100% electric car. Hybrid cars use petrol and we can't allow that"

we: "suuure, I get that. But the price of electricity here still hasn't come down, everyone already has personal petrol reserves, and your cars are only provided with batteries from congonese child labor mines. Can we pleeease have the half-way option so that I can use less petrol for e.g. small distance travel, but still using petrol for country-sized movement?"

vendor: "no, we only support 100% electric car. Everything smaller is outside our requirements"

Real economics would've provided competition to fullfill demand - but currently Graphene is the only well-known vendor, so complaints will keep coming

why not to make it heap-only type? it seems such a useful addition to type system, why ignore it due to one usecase?

you got it wrong way around

the CONSUMER criteria is "we want better independent security ON DEVICES WE ALREADY OWN"

complaints like in this thread are symptoms of unfullfilled demand - and they can't be solved by saying "oh gosh, what a stupid demand that doesn't agree with our supply"

microsoft spent a lot of time asking questions to the author - and then rolled out Azure copy of the lib

author went public "how dare they use me like that" - but he did make it BSD himself, it's his problem

C and C++ are about types before names - and modifying that is simply a change for the sake of a change, needless and useless. There's a lot of education enertia behind it - and effort should be spent on fighting what matters (like smart pointers), not hip/non-hip declaration style

decltype(a*b) is the only good "escape hatch"-type excuse for it, but idk why everyone make such a big deal out of it - when was the last time return type was both unpredictable AND needed to be specified? by that point you're already too deep

isn't the problem that rw is still r, so passes checks for both?

can't you make one rw and the other r(-w)?

sure, "contributing is cheaper than maintaining a fork" is true most of the time - but the moment new Microsoft comes in with "embrace, extend, extinguish" (or just copy and change), you're doomed

and heck, we had that exact thing happen last autumn, iirc - making big news on this website

ichtiozaur, dolphin/orca

anything else?

it's precision

no net force, but net potential energy - thus gravitational dilation

even the one you cult over

3 months have passed, 9 to go :)

if you're a teacher and one student per class does the same thing - it's common. Even though it's only 1/25 or 1/30 of all students