On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote:
> On Tue, 21 Jul 2020 at 02:28, Marek Polacek <pola...@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.
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?
Marek
