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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
