Manna added inline comments.
================
Comment at: clang/include/clang/Sema/Sema.h:1790
SemaDiagnosticBuilder(const SemaDiagnosticBuilder &) = default;
+ SemaDiagnosticBuilder &operator=(const SemaDiagnosticBuilder &) = delete;
~SemaDiagnosticBuilder();
----------------
tahonermann wrote:
> aaronpuchert wrote:
> > tahonermann wrote:
> > >
> > Being explicit is certainly a good thing, but the C++ committee wants to go
> > into the direction of "copy/move operations are implicitly deleted if any
> > of them or the destructor is user-declared." See
> > [depr.impldec](https://eel.is/c++draft/depr.impldec). It is already
> > partially the case, for example here. So why do need to spell something out
> > explicitly when the language goes into the direction of being even more
> > implicit?
> I have low expectations of that deprecation ever being acted on. In fact,
> there have been discussions about un-deprecating it because of the lack of
> such intent.
>
> The motivation for deprecation is not based on a judgement of whether
> implicit or explicit is better, but rather based on a safety argument; if a
> copy constructor or destructor is user-declared, that is probably because
> some form of resource management is needed that won't be performed by the
> defaulted copy assignment operator. Thus, defining the implicit copy
> assignment operator as deleted would avoid the possibility of the compiler
> injecting bugs in the program.
>
> The rules for when the copy vs assignment operators are implicitly defined as
> deleted can be hard to remember. I think being explicit is useful if only to
> indicate that the author thought about whether such operations should be
> provided. Since we don't have a principled reason for defining these
> operations as deleted, it might not be a bad idea to add a comment that
> states something like "The copy/move assignment operator is defined as
> deleted pending further motivation".
Thank you @tahonermann for the comments and the updates about the deprecations
discussion.
>>t might not be a bad idea to add a comment that states something like "The
>>copy/move assignment operator is defined as deleted pending further
>>motivation".
I like the idea of adding a comment since pending standard decision. I have
updated my patch with the comments
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D150411/new/
https://reviews.llvm.org/D150411
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
