A concept-centered standard library for C++20, enabling safer and more reliable products and a more modern feel for C++ code.; Also home of Subdoc the code-documentation generator.
Noting that rust has vec![1, 2, 3] which is a macro to create vectors from arbitrarily long sets of inputs, and it does this without templates/variadics.
Some ideas:
Stamp out a ton of ctors like Vec<T>(T), Vec<T>(T, T), Vec<T>(T, T, T) ... etc and just hide all but one from docs. This avoids combinatorial explosion in codegen otherwise caused by passing many different types. But every function would get generated for every Vec right?
sus_vec(T, ...) macro that figures out how many args it was given, calls Vec::with_capacity() and then push() for each argument, inside a lambda to keep things in scope and then returned.
#define sus_vec(T, ...) \
[&] { \
constexpr ::sus::num::usize s = SIZE_OF_VAR_ARGS??(__VA_ARGS__); \
auto v = ::sus::Vec<T>::with_capacity(s); \
FOR_EACH(PUSH_IT, __VA_ARGS__) \
return v; \
}()
#define PUSH_IT(it) v.push(it);
Something like that.
Generate a warning when you call Vec(...) with too many things, by calling some [[warning]] function, and point the caller to a Vec<T>::with_initializer_list(std::initializer_list<T>).
Also in https://thephd.dev/sol3-compile-times-binary-sizes, it points out the enormous cost of variadics. But initializer_list is not a good option as it breaks move-only things.
Noting that rust has vec![1, 2, 3] which is a macro to create vectors from arbitrarily long sets of inputs, and it does this without templates/variadics.
Some ideas:
Vec<T>(T),Vec<T>(T, T),Vec<T>(T, T, T)... etc and just hide all but one from docs. This avoids combinatorial explosion in codegen otherwise caused by passing many different types. But every function would get generated for every Vecsus_vec(T, ...)macro that figures out how many args it was given, calls VecSomething like that.
[[warning]]function, and point the caller to aVec<T>::with_initializer_list(std::initializer_list<T>).