operator void()

[floria...@gmail.com]

For now, operator void() is allowed but never used (unless explicitly called with obj.operator void() ).
I propose to add a meaning to this conversion operator: it is called when ever the result of an expression isn't used.
First, this is not the same as calling the destructor on a temporary object.

This would allow to call a specific function with that kind of syntax:

myobj;
myobj.mymember;

Basically, if the result of an expression is not used, it calls the (implicit) operator void().
If you write (void) myobj or static_cast<void>(myobj), it calls the explicit operator void().
If you write reinterpret_cast<void>(myobj), nothing happens: no operator void() is called.
If the operator void() should be called but doesn't exist, nothing happens: no operator void() is called.
If the operator void() should be called but is deleted: the program is ill-formed.
If a function parameter is not used within the function body, nothing happens: no operator void() is called.

I'm not sure what kind of uses this can have, but this would add a meaning to something that is already syntactically valid (you already can write operator void() ), and some languages allow to call a function without parenthesis.
I'm pretty sure some people already have some use cases for this kind of features like static analysis of the code.

The pitfall I can see with this are the following:

• With the previous rules, myobj = expr; would call the operator void() because the operator=() returns a reference to the object which is not used.

A solution to this could be to not return a reference to the object after an affectation (this breaks the affectation chaining) or return a wrapper to the reference (add boilerplate).

[Brittany Friedman]

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3cb45c49-fc41-4922-b35c-49871dd00a54%40isocpp.org.

If you don't even have one practical example of how this would be useful then I don't know why you would expect the committee to spend time considering it.

Other proposals, like "regular void", could make use of operator void in ways that conflict with your idea.

[floria...@gmail.com]

Le mardi 7 mars 2017 17:05:31 UTC+1, Brittany Friedman a écrit :

On Tue, Mar 7, 2017 at 9:56 AM, <floria...@gmail.com> wrote:

For now, operator void() is allowed but never used (unless explicitly called with obj.operator void() ).
I propose to add a meaning to this conversion operator: it is called when ever the result of an expression isn't used.
First, this is not the same as calling the destructor on a temporary object.

This would allow to call a specific function with that kind of syntax:

myobj;
myobj.mymember;

Basically, if the result of an expression is not used, it calls the (implicit) operator void().
If you write (void) myobj or static_cast<void>(myobj), it calls the explicit operator void().
If you write reinterpret_cast<void>(myobj), nothing happens: no operator void() is called.
If the operator void() should be called but doesn't exist, nothing happens: no operator void() is called.
If the operator void() should be called but is deleted: the program is ill-formed.
If a function parameter is not used within the function body, nothing happens: no operator void() is called.

I'm not sure what kind of uses this can have, but this would add a meaning to something that is already syntactically valid (you already can write operator void() ), and some languages allow to call a function without parenthesis.
I'm pretty sure some people already have some use cases for this kind of features like static analysis of the code.

The pitfall I can see with this are the following:

• With the previous rules, myobj = expr; would call the operator void() because the operator=() returns a reference to the object which is not used.

A solution to this could be to not return a reference to the object after an affectation (this breaks the affectation chaining) or return a wrapper to the reference (add boilerplate).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3cb45c49-fc41-4922-b35c-49871dd00a54%40isocpp.org.

If you don't even have one practical example of how this would be useful then I don't know why you would expect the committee to spend time considering it.

Other proposals, like "regular void", could make use of operator void in ways that conflict with your idea.

To be honest with you, I had thought about some use-cases when I came up with this idea, but forgot them while thinking about the shape this could have.
In fact, I wouldn't have published this if I hadn't seen the post about the semi-colon operator overloading (which is basically the same idea, but a little different).

A really easy use case is to have an hard error when an object is returned and never used. There are other proposal to this very use case. This is another approach (which can be used for other things).

[Dan Raviv]

A really easy use case is to have an hard error when an object is returned and never used. There are other proposal to this very use case. This is another approach (which can be used for other things).

For that specific use case, you have the new [[nodiscard]] attribute.

[Thomas Köppe]

Perhaps you could avoid a few complications if you restricted your design to prvalue expressions only. Then things like assignment operators wouldn't all require exceptional treatment, for example.