My interpretation: add a library call for memory requests of at-least n bytes, putting the burden of look-ahead allocation on memory allocator implementers.
My opinion: terrible design decision. Advancing this idea to the memory allocator interface would open ways for strange performance differences based on compiler and CRTs, unpredictably so. The MSVC CRT has a long-standing approach of actually GROWING memory in-place, and if that fails going the new-allocation route. But no, don't you misunderstand it, it is not the same as the realloc function call, go research _expand from the MSVC CRT! The developer does get a boolean-feedback if the growing-inplace has succeeded or not, then he can issue a subsequent new-allocation with move-semantics to keep the C++ rules in-check! IMO this is a much better design idea but strange shit does find it's way into the C++ language sometimes anyway. Just like in every software it will take some time to temper and will fade out.
The developer should be poked to make a guess at how much he would need because HE CAN DO THE SMART MATH! Randomly guessing what the developer would need is a terrible fate. My guess is that those strange people that think allocation of 2^n blocks for encapsulation is best approach, those people are driving this addition to the language... I whole heartedly disagree.
How about actually taking ideas from MSVC for once, C++ committee???
Re: C++ Language Design (2021-09-15 21:20 by quiret #88044)
I wonder if the C++ concepts are meant to be friendship-boundary resistant. According to the C++20 friend statement description on cppreference.com, you cannot befriend a concept. But then there are concepts like this one:
According to that website, the std::constructible_from concept depends on the struct/class std::is_constructible_v but this struct is not friendship-boundary resistant. For example, you could have class A and B which are friends of each-other and B has its constructors private. If A where to query B if it can construct it using some parameters, std::is_constructible_v MUST return false because the struct or class has no access to B's constructors. But I wonder, since you cannot befriend concepts, this access denial should not happen by using std::constructible_from? The access check should be done against the location of where the concept is being used and not the point in the source where the concept was defined.