[PATCH] c++: Fixing the wording of () aggregate-init [PR92812]

[Ville Voutilainen]

On Tue, 21 Jul 2020 at 21:56, Marek Polacek <polacek@redhat.com> wrote:
>
> On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote:
> > On Tue, 21 Jul 2020 at 02:28, Marek Polacek <polacek@redhat.com> wrote:
> > >
> > > P1975R0 tweaks the static_cast wording: it says that "An expression e can be
> > > explicitly converted to a type T if [...] T is an aggregate type having a first
> > > element x and there is an implicit conversion sequence from e to the type of
> > > x."  This already works for classes, e.g.:
> > >
> > >   struct Aggr { int x; int y; };
> > >   Aggr a = static_cast<Aggr>(1);
> > >
> > > albeit I noticed a -Wmissing-field-initializer warning which is unlikely to be
> > > helpful in this context, as there's nothing like static_cast<Aggr>(1, 2)
> > > to quash that warning.
> > >
> > > However, the proposal also mentions "If T is ``array of unknown bound of U'',
> > > this direct-initialization defines the type of the expression as U[1]" which
> > > suggest that this should work for arrays (they're aggregates too, after all).
> > > Ville, can you confirm that these
> > >
> > >   int (&&r)[3] = static_cast<int[3]>(42);
> > >   int (&&r2)[1] = static_cast<int[]>(42);
> > >
> > > are supposed to work now?  There's no {} variant to check.  Thanks.
> >
> > I don't know what it means to cast something to an array; doesn't that create
> > an array prvalue? Is that a thing?
>
> Yes, I imagined this would be similar to
>
> using T = int[3];
> int (&&r)[3] = T{1, 2, 3}; // binds to array prvalue, lifetime extended
>
> but I'd like to avoid allowing code that isn't supposed to work.

Okay. I think it's remotely reasonable that a static_cast<T>(42) would
work for an array, then.
And by a natural extension, that using the concrete type would also
work. That seems consistent,
but doesn't seem like it rises to the level of "an important part of
the design". Trafficking arrays
around in generic code is already hard, because they don't behave like
other things do, so the
answer to "was this supposed to work?" is pretty much "it wasn't
considered during the design phase".

> We also might want to consider if we want to extend the lifetime of r/r2 in my
> previous example (I think so; DRs 1299/1376).  Worth bothering CWG?

I think it's a good idea to bother CWG with both the above and the
lifetime extension.