[abnercoimbre]

Meaning it died at committee?

[jcranmer]

From what I can see in the WG14 document log [1], it never made it to the committee in the first place.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

[Animats]

Never pushed it that far. Mentioning safety in a C or C++ context was viewed very negatively back then.

[uecker]

We are working towards this though and a lot of this already works:

https://godbolt.org/z/EP3cP3qGs

[uecker]

It is a struggle though to get the improvements through the committee. Especially the C++ folks from the Clang side fight very hard against it, this is - for example - why we not have forward declarations where I already had weak consensus, but the clang area team made it clear they will never implement it.

[einpoklum]

But C and C++ do have forward declarations [1]... can you elaborate on what exactly you were trying to promote that was rejected?

[1] : https://en.wikipedia.org/wiki/Forward_declaration

[wavemode]

I assume he's referring to: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3207.pdf

[eqvinox]

The vec macros currently there directly call realloc()… that's gonna exclude any custom allocator setups… and the string code uses the vecs :/

[1718627440]

The allocator interface is defined via these names. Just supply your own realloc. Of course you need to satisfy the constraints of realloc guaranteed to the compiler, or you need to invoke it in freestanding mode.

[eqvinox]

That doesn't work for pool allocators like https://apr.apache.org/docs/apr/1.5/group__apr__pools.html and neither does it work for our allocator https://docs.frrouting.org/projects/dev-guide/en/latest/memt... that takes an allocation group argument.

[uecker]

The example shown does not use vec from my experimental library.

But yes, I was thinking about making a custom-allocator version of vec.

[uecker]

But since you mentioned it, the interoperation of vec/span and arrays is also really nice in my opinion: https://godbolt.org/z/nYe48jh5d