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

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

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:

>




> Ah.  If you want to be able to find this thing without a Sema around in order to
>  handle deserialized expressions by just caching things in the ASTContext, yes,
>  I agree that it would be difficult to build a `CXXConstructExpr` correctly.  I don't
>  fully understand the goal of avoiding serialization here, though.

Perhaps I don't fully understand the goal of avoiding serialization either.

>>> STLs *frequently* make use of default arguments on copy constructors (for
>>>  allocators). I agree that it’s unlikely that that would happen here, but
>>>  that’s precisely because it’s unlikely that this type would ever be
>>>  non-trivial.
>> 
>> A couple of points. First, when I say copy constructor, I mean the special member, which
>>  cannot have default arguments,
> 
> 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.

>> 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.


https://reviews.llvm.org/D45476