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

[Marek Polacek]

On Tue, Jul 21, 2020 at 10:03:37PM +0300, Ville Voutilainen via Gcc-patches wrote:
> 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".

Fair enough.

> > 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.

I'll email core then.  Thanks for responding!

Jason, I think the patch still makes sense as-is; presumably we can follow up
with the controversial bits (arrays) later.

Marek