On Tue, 21 Jul 2020 at 22:39, Marek Polacek <pola...@redhat.com> wrote: > > 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.
Sorry. :) None of the main driving-use-cases for allowing paren-init of aggregates involved arrays. They were to some extent expected to hitch a ride since they are aggregates, but otherwise they never received particular design-level lovin'. It seemed plausible to be able to paren-init a member array in a ctor-initializer. Paren-initializing automatic storage duration variables requires a typedef anyway. So the casting cases have not been fully fledged design-wise, and that's mostly just oversight. Or lack of energy, if you wish.
