C.60 and C.63: Should we allow operator= to return void?

[hsutter]

We have;

• C.60: Make copy assignment non-virtual, take the parameter by const&, and return by non-const&
• C.63: Make move assignment non-virtual, take the parameter by &&, and return by non-const&

The only reason to require "return by non-const&" is to enable chaining (e.g., a=b=c;).

In recent conversations, I've heard sympathy for not requiring chaining and allowing a void return type from operator=. If so, we should consider changing the Guidelines to allow a void return from operator= so that code that does that won't get flagged by Guideline checkers.

Proposed solution: Changed the end of each the C.60 and C.63 titles to be "... and return by non-const& or void" and update the bodies similarly.

[JohelEGP]

Why not use the suppression attribute specified by https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#inforce-enforcement?

[beinhaerter]

I know you find void return type useful when using = delete. Are there also other cases where one would use void return type? When would I want to disable chaining? Are there cases where chaining could hurt?

Side note: I am not a friend of chaining, I am not using it. But I don't yet see why I should prohibit it to limit clients of my classes.

[hsutter]

Yes, yes, and possibly yes, respectively.

This question happened to come up in a recent conversation among the editors, and I heard sympathy for the position that chaining might be generally undesirable or at least not be carrying its weight. It's not often used, and if we knew what we know today back when it was designed (aka "if we had a time machine") a non-void return and chaining might not be in the language today. That's one reason I just wrote void in the GSL commit here. And then I opened this Issue when you correctly pointed out that the Guidelines actually require a non-void return in C.60 and C.63 today (thanks again for pointing that out).

To be clear, this is not a rant against chaining by any means. We're not proposing taking it out of the language or banning it or anything. This Issue is narrowly about whether it makes sense for the Guidelines to minimally just stop requiring chaining, that's all, because I had heard sympathy for considering it a reasonable design choice.

[JohelEGP]

Proposed solution: Changed the end of each the C.60 and C.63 titles to be "... and return by non-const& or void" and update the bodies similarly.

Why not limit the scope to an Exception item? Raising it to the title and main body seems to me like a step backwards from the standard object concepts, which require chaining and the guidelines are in favor of.

[BenjamenMeyer]

Not a friend of chaining - I rarely if ever use as I find readability better when minimizing changing, however:

In recent conversations, I've heard sympathy for not requiring chaining and allowing a void return type from operator=. If so, we should consider changing the Guidelines to allow a void return from operator= so that code that does that won't get flagged by Guideline checkers.

This would seem to just add confusion to the language since you could no long rely on the operators to return the correct type when some operators return void - a. non-return value. Operators are confusing enough to setup as it is.

Put another way:

a = b

should always be something to reliably work; when b is void or might return void that's just going to create confusion.

You don't necessarily need chaining (a = b = c) for this to be a problem.

[cubbimew]

Chaining might be red herring as it's just a special case of lvalue use. Though I agree I can't recall intentionally using assignment expressions that way outside of old C's file-reading loops while ((ch=getchar()) != EOF)

[neithernut]

The following might be reasonably common:

auto foo() -> std::unique_ptr<...>;

if (auto thing = foo()) {
   // ...
}

Though it may not be directly affected due to the declaration inside the condition. I'm too lazy to look it up right now. However, presumably many will expect that you can move the declaration out of the condition (any may need to due to being stuck with an old standard):

auto foo() -> std::unique_ptr<...>;

std::unique_ptr<...> thing;
if (thing = foo()) {
   // ...
}

Edit: yes, I'm aware that most would choose the saner option of also moving the initialization out of the condition if they cannot, for whatever reason, declare thing in the condition.

[JohelEGP]

The linked GSL commit is about using void when =deleteing operator=, which is very reasonable. Beyond that, a weird type that wants to prohibit chaining, is not contextually convertible to bool, and wants to be assignable but not a model of assignable_from<T> for all T, seems very niche.