On 18.02.21 22:28, Andrew Sutton wrote:
> We should be able to make std::get<> work with structs with just reflection:
>
> template<std::size_t N, plain_struct T>
> decltype(auto) get(const T& obj) {
> return obj.[:data_members_of(^T)[N]:];
> }
>
> That can get a little more complicated when you add inheritance and
> access specifiers, but not much. Although, now that I think about, we
> could just replace the usual definition of std::get with something like
> this, and it automatically works for both tuples and structs.

Indeed. Ever since I started thinking about reflection, I considered
tuple and struct the same thing.

> A little constexpr if sprinkled in there also makes it work for arrays.

Excellent idea. Even better :-)

> I will continue avoiding tuple cat for now :)
>
> (Every time I see "tuple cat" or tuple_cat, I keep wanting to read it as
> "Honky Cat", as in the Elton John song).

Interesting association, haven't heard that in a while :D

> > constexpr tuple(T const&... args)
> > : ... [: data_members_of(^tuple)
> :]([:parameters_of(current_function()):])
> > { }
>
> While Barry's proposal is much shorter, I would prefer something like
> this, as it would work with named members :-)
>
>
> The idea of declaring packs vs. naming members is interesting. There are
> design objectives that motivate both uses, but I don't know if there are
> obvious criteria that push a design in either direction. Maybe it's just
> "I want names" vs. "I don't care about names".

To me having members with actual names is part of the "a tuple is just a
struct and vice versa" philosophy.

And it would sometimes allow to avoid the cognitive overhead of
std::get<1>(t).

> So yes, go and find examples that are hard/clumsy without reflection
> and
> start translating them. We need real life examples :-)
>
>
> My experience has been that it is very hard to simultaneously design and
> implement language features and also dogfood them. It's also more than a
> bit self-reinforcing. Having other people bring problems --- which you
> have a great history of :) is excellent fodder for design discussions.

Fair enough. And I certainly intend to provide more problems while
hoping for others to provide the required language feature :-)

"It's like trying to find gold in a silver mine" (and succeed).

Cheers,

Roland