[std-proposals] Expansion of non-static data members

[Columbo]

I realise this overlaps with the existing discussions on first-class tuples
in the language, but is there any current propositions on

template <typename... T> struct X {T... t;};

It would be nice to have this in some minimalistic manner until we have a
clear idea of what other surrounding features are meant to look like. I
remember seeing papers discussing syntax for dependent pack members, e.g.
Richard proposed .... IIRC (operator ...). Has someone tracked the progress
of these papers?

[m***@gmail.com]

Here, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1061r0.html

I don't know of any other active papers.

Post by Columbo
I realise this overlaps with the existing discussions on first-class
tuples in the language, but is there any current propositions on
template <typename... T> struct X {T... t;};
It would be nice to have this in some minimalistic manner until we have a
clear idea of what other surrounding features are meant to look like. I
remember seeing papers discussing syntax for dependent pack members, e.g.
Richard proposed .... IIRC (operator ...). Has someone tracked the
progress of these papers?

[Richard Smith]

One problem with a proposal such as this is that when parsing something
like:

template<typename T> void f(X x) { g(x.y.a + h(x).z.b ...); }

... the compiler has no idea where the packs are within the pack expansion.
That's pretty much fatal to more or less all current implementation
strategies for variadic templates.

If we had explicit syntax to identify where the packs are: (note: strawman
syntax)

template<typename T> void f(X x) { g(x.y. ...a + h(x). ...z.b ...); }

... then the compiler could work out that it has to first substitute into
'x.y' to determine the arity of 'a', and into 'h(x)' to determine the arity
of 'h(x).z'.

Another potential stumbling block for most proposals in this area is that
they introduce the possibility of encountering packs outside templates;
when processing code that involves potentially-variadic pack expansion,
some compilers enter a fundamentally different parsing mode (their usual
mode essentially generates code from expressions as they go, but for a pack
expansion you need to do something quite different because you don't know
how many times you'll need to repeat any given construct -- and that number
might even be zero!); if pack expansions can appear out of the blue,
anywhere, then this mode must be used all the time, which might have a
significant deleterious effect on compilation times. (However, the one
compiler that I know of that does something like this has undergone a
fairly substantial rewrite, so I don't know whether this is still a problem
for any current C++ compilers.)

The challenge would be to find a way to make this work without the result
being ugly, and without ruling out current common implementation strategies.

Post by m***@gmail.com
Here,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1061r0.html
I don't know of any other active papers.

Post by Columbo
I realise this overlaps with the existing discussions on first-class
tuples in the language, but is there any current propositions on
template <typename... T> struct X {T... t;};
It would be nice to have this in some minimalistic manner until we have a
clear idea of what other surrounding features are meant to look like. I
remember seeing papers discussing syntax for dependent pack members, e.g.
Richard proposed .... IIRC (operator ...). Has someone tracked the
progress of these papers?

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%40isocpp.org?utm_medium=email&utm_source=footer>
.