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