A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/cplusplus/CWG/issues/578 below:

CWG2915 [dcl.fct] Make "this void" invalid as explicit object parameter · Issue #578 · cplusplus/CWG · GitHub

Full name of submitter: Anoop Rana

Reference (section label): [dcl.fct]

Issue description:

Currently there is no restriction on the type of the explicit object parameter. Consider the following example for which we observe compiler divergence:

struct A {
    void f(this void);

};
int main() 
{
    A a;
    a.f(); //gcc: Nope, msvc:Nope, clang:OK, EDG:OK
}

If [dcl.fct] is applied here, then it will turn the explicit object member function into an implicit object member function with no non-object parameter(which I don't think is intended). If so, then a.f(); is well-formed. But turning an explicit object member function to an implicit object member function may be unexpected and surprising and I don't think it should be valid.

So we can just disallow the use of void in the explicit object parameter. That is, make this void invalid altogether.

Note that there is also issue Is void adjustment and cv-qualifier adjustment applied when considering corresponding overload that explains that overloading explicit member function with this void with implicit object member function with no non-object parameter, is well-formed as per current wording. With the suggestion of this current issue(by making this void ill-formed), the program given in that issue will also become ill-formed.

Suggested resolution:

Make this void invalid as explicit object parameter.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4