This is an archive of the discontinued LLVM Phabricator instance.

Declare std::tuple_element as struct instead of class
ClosedPublic

Authored by jdoerrie on Apr 1 2019, 8:39 AM.

Diff Detail

Event Timeline

jdoerrie created this revision.Apr 1 2019, 8:39 AM

Did you check the places that inherit from tuple_element? The public/private bits change between class and struct.

Did you check the places that inherit from tuple_element? The public/private bits change between class and struct.

Never mind. I was thinking of something else; I don't think that anything inherits from tuple_element

Did you check the places that inherit from tuple_element? The public/private bits change between class and struct.

Never mind. I was thinking of something else; I don't think that anything inherits from tuple_element

Right, there shouldn't be any inheritance. Some of the public: access specifications are now redundant, though. Instead of

template <size_t I, class... Types>
struct tuple_element<I, tuple<Types...> >
{
public:
    typedef Ti type;
};

we could now simply say

template <size_t I, class... Types>
struct tuple_element<I, tuple<Types...> >
{
    typedef Ti type;
};

Right, there shouldn't be any inheritance. Some of the public: access specifications are now redundant, though.

And I think that you should get rid of them.

Right, there shouldn't be any inheritance. Some of the public: access specifications are now redundant, though.

Can you please fix those?

ldionne requested changes to this revision.Apr 1 2019, 9:15 AM
This revision now requires changes to proceed.Apr 1 2019, 9:15 AM
jdoerrie updated this revision to Diff 193106.Apr 1 2019, 9:24 AM

Remove redundant public: access controls

ldionne accepted this revision.Apr 1 2019, 9:25 AM
This revision is now accepted and ready to land.Apr 1 2019, 9:25 AM
mclow.lists accepted this revision.Apr 1 2019, 9:28 AM

I'm less enthusiastic about this change than the one for PR39871, because there we were being inconsistent with ourselves.
However, my lack of enthusiasm is no reason not to land this.

I'm less enthusiastic about this change than the one for PR39871, because there we were being inconsistent with ourselves.
However, my lack of enthusiasm is no reason not to land this.

Thank you for accepting. I understand your point, but you could argue that this change fixes a inconsistency between tuple_size and tuple_element. As I don't think I have commit access, could one of you commit this change for me?

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 1 2019, 9:38 AM