konstantinua00

...what are you talking about?

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

no, correct analogy would be

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

there are smaller security options

one thing I never understood about VLAs - discussion about them always hits a "can't put it on stack safely" and gets halted, forever

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

> The other devices don't meet the criteria

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"

4-5 versions of the same phone in the gigantic sea of possible devices

iirc, some kubernetes library under BSD

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

aka that's what read-only is for write?

I prefer to never use it

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

can't it be solved by negative traits?

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)?

using BSD/MIT licences is like betting against black swan event

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

why would latency matter if the trading we're talking about isn't high-speed?

how many times things evolved into sharks?

ichtiozaur, dolphin/orca

anything else?

there is no true value, so it's not accuracy

it's precision

that's the argument, yes

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