[PATCH] D45476: [C++2a] Implement operator<=> CodeGen and ExprConstant

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D45476#1088180, @EricWF wrote:

> OK, As I see it, we have two choices:
>
> (1) Stash the expressions in Sema and import them like
>
> In https://reviews.llvm.org/D45476#1088047, @rjmccall wrote:
>
> > I'm sorry, but this is just not true.  The formation rules for a copy constructor are laid
> >  out in [class.copy]p2, and they explicitly allow default arguments.
>
>
> Don't apologize because I'm wrong :-P. Thanks for the correction.


It's been a thorn in my side quite a bit, too. :)

>>> Second, in the synopsis for the STL types, no constructors are declared. Although I don't
>>>  think the standard spells it out anywhere, I believe this forbids the types from having user
>>>  defined constructors (though perhaps not user-declared explicitly defaulted constructors.
>>>  For example adding a user defined destructor would be non-conforming since it makes
>>>  the types non-literal).
>> 
>> That would certainly be helpful, but I don't think it's true; in general the standard describes
>>  what things are guaranteed to work with library types, but it doesn't generally constrain
>>  the existence of other operations.
> 
> I think this is somewhat of a moot point, but I think the constraint is in `[member.functions]p2`:
> 
>> For a non-virtual member function described in the C++ standard library, an implementation may declare
>>  a different set of member function signatures, provided that any call to the member function that would
>>  select an overload from the set of declarations described in this document behaves as if that overload were selected.
> 
> My argument is that because the class synopsis for the comparison category types doesn't describe or declare
>  the copy constructor, so the implementation *isn't*  free to declare it differently.

The type has to allow itself to be constructed with an l-value (whether const or not)
of its own type in order to be CopyConstructible.  However, that's just a statement
about the *signatures* of the type's constructors; it doesn't say anything about whether
those constructors are user-defined, nor does it limit what other constructors might
be provided as long as they don't somehow prevent copy-construction from succeeding.
(And in somewhat obscure cases, constructing a T with an l-value of type T won't
even select a copy constructor, and that's legal under the standard, too.)  All that matters,
absent requirements about T being an aggregate or trivially-copyable type, is that the
construction is well-formed and that it has the effect of copying the value.

Anyway, I agree that this is moot.

John.


https://reviews.llvm.org/D45476