c++ - What is the status on dynarrays?

Question

gcc 4.9 now has support for n3696 (Runtime-sized arrays with automatic storage duration). n3662 says:

In N3497 Runtime-sized arrays with automatic storage duration, Jens Maurer proposes arrays with runtime bound. These arrays are to std::dynarray as normal fixed-size arrays are to std::array.

In this mailing list, Jonathan Wakely says:

We should add a C++14 status table to the manual but in the meantime here's a quick summary of the library status.

...

These ones are missing:

• N3672 A proposal to add a utility class to represent optional objects
• N3655 TransformationTraits Redux
• N3662 C++ Dynamic Arrays
• N3644 Null Forward Iterators

The traits one is simple but a bit tedious and the iterators one probably only affects debug mode, but the other two are substantial pieces of work. Is anyone planning on working on or yet?

However, n3662 also says:

Instead of adopting C variable-length arrays we propose to define a new facility for arrays where the number of elements is bound at construction. We call these dynamic arrays, dynarray.

I can't seem to find dynarray using a quick CTRL+F on the gcc pages. So is dynarray going to be implemented soon, and will variable length arrays stay or will it disappear?

Answer 1

std::dynarray was intended to go with c++14 at first. However, it was later decided that std::dynarray would be moved to an "Array TS" which may also include some std::array_view class. The main reason is that the committee did not agree on some points concerning heap-allocation versus stack-allocation in some cases (what if you try to allocate an std::dynarray with new). Therefore, it was decided that it would be delayed. There are still some ongoing discussions about what should be done.

The class won't be ready for C++14. It will probably come with the Arrays TS or C++17.

Update: std::dynarray wasn't in C++14, won't be in C++17, the Arrays TS has been discontinued, so there probably won't be anything close to std::dynarray in the standard before long. If I understand the current position of the standard correctly, rather than magical runtime-sized arrays, the committee would rather come up with a general solution for runtime-sized classes, but every suggestion so far has been rejected.