> > This is subjectively horrible and, more objectively, would create
> > longer mangled names and additional RTTI.
> Yeah, it's a neat trick but probably not appropriate to use within the
> standard library.
I understand. I was genuinely curious about whether this would do the trick.
In fact,
On Tue, 2 Apr 2024, Jonathan Wakely wrote:
> On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote:
> >
> > Just out of curiosity: would this also work?
> >
> > template
> > struct _Absent {};
> >
> > template
> > using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp,
> > _Disc>>;
> >
On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote:
>
> Just out of curiosity: would this also work?
>
> template
> struct _Absent {};
>
> template
> using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, _Disc>>;
>
> That would avoid having to type 0, 1, ... manually.
This is
Just out of curiosity: would this also work?
template
struct _Absent {};
template
using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp,
_Disc>>;
That would avoid having to type 0, 1, ... manually.
On Mon, 1 Apr 2024 at 23:16, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This is a layout change for some specializations of slide_view, but
better to do that now than change it between gcc 14 and 15.
OK for trunk.
>
> -- >8 --
>
> Currently
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Currently __maybe_present_t maps to the same empty class
type independent of T. This is suboptimal because it means adjacent
__maybe_present_t members with the [[no_unique_address]]
attribute can't overlap even if the
