Ref-qualified member functions

[Matthew Dempsky]

The Chromium style guide says these are disallowed because of the Google C++ style guide, but the Google C++ style guide doesn't say anything about them, and they're being used within Google's internal code base.  (E.g., search for ") && {" lang:c++.)

dcheng@ reports on IRC that "MSVC [2013] exploded violently all over [ref-qualifiers] when I tried them", but https://msdn.microsoft.com/en-us/library/hh567368.aspx claims they're supported in MSVC 2015.

Once we have MSVC 2015, is there anything else preventing use of ref-qualifiers in Chromium C++?

In the mean-time, could we still opportunistically use ref-qualifiers for non-overloaded member functions that should only be used on rvalues?  E.g., in base/compiler_specific.h, something like:

    #if defined(COMPILER_MSVC) 

    #define RVALUE_ONLY /* sad panda */

    #else

    #define RVALUE_ONLY &&

    #endif

Then we could write code like:

    class Foo {

     public:

      Foo();

      ~Foo();

      void Bar() RVALUE_ONLY;

    };

and at least usages like:

    void f() {

      Foo().Bar();  // ok

      Foo foo;

      std::move(foo).Bar();  // ok

      foo.Bar();  // ERROR

    }

could be enforced correctly on non-MSVC compilers today.

MSVC would unfortunately not catch the misuse (until we start using 2015), but that's no different than how it doesn't catch misuse of WARN_UNUSED_RESULT functions today.

[Daniel Cheng]

Though it's not mentioned in the external copy, the internal Google style guide definitely bans ref-qualifiers: go/style#C++11 (search for ref-qualifiers)

Daniel

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF52%2BS5V50PBJsuSCUNu0Rovb7Hcy-F%3DmxPfRUve7-rszjGCwQ%40mail.gmail.com.

[James Robinson]

This feature is currently banned by the Google C++ style guide.  See the recent internal thread (conclusion on Nov 11th) for more discussion.

- James

--

[Matthew Dempsky]

On Mon, Dec 14, 2015 at 3:32 PM, Daniel Cheng <dch...@chromium.org> wrote:

Though it's not mentioned in the external copy, the internal Google style guide definitely bans ref-qualifiers: go/style#C++11 (search for ref-qualifiers)

[For non-Googlers, the relevant part of this internal-only style guide addendum states:

Decision:

C++11 features may be used unless specified otherwise. In addition to what's described in the rest of the style guide, the following C++11 features may not be used:

• [...]
• Ref-qualifiers on member functions, such as void X::Foo() & or void X::Foo() &&, because of concerns that they're an overly obscure feature.
• [...]

]

It seems difficult to reconcile that ban with the fact that ref-qualifiers *are* being used on member functions internally.

[Daniel Cheng]

It's possible to ask for a style exception to the rules. Historically, I believe the C++ library team has used requests for style exceptions to guide future changes to the style guide.

Daniel

[Dana Jansens]

c-style-arbiters grant exceptions to rules, I assume that is why. There's some discussion of this concept of exceptions in particular about ref-qualifiers in c-style@ if you search "waivers".

AFAICT the rule exists because of a lack of evidence that there are cases where code is more clear to read with ref-qualifiers than without, not because of concerns of safety/correctness. Presumably when there are enough exceptions granted, there would also be enough evidence that this isn't so exceptional and they would allow it.

Do you have some good examples in mind? We've been considering using them to implement parts of base::Callback, which would of course help make it more familiar.

[Jeremy Roman]

Personally, I've never seen this used, the only reasonable case I'm aware of is base::Callback (which is one of those cases where an arcane implementation is reasonable). Unless there's an example of why this would be useful in general code, an "only with special approval" rule seems right to me.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaRO1xx8kixddpx5hzCsMbwR-AursfJV%3D%3DavxNAC3mnrkQ%40mail.gmail.com.

[Jeremy Roman]

Closing the loop here: styleguide/c++/OWNERS met, and this feature remains banned, except by explicit approval.

[pkas...@chromium.org]

On Thursday, January 7, 2016 at 5:00:16 PM UTC-8, Jeremy Roman wrote:

Closing the loop here: styleguide/c++/OWNERS met, and this feature remains banned, except by explicit approval.

Resurrecting this long-dead thread:

The internal styleguide no longer bans these.  I think we should similarly change to allowing them.  Personally I'm not sure we need guidelines like "use rarely" because I think people already will.

PK

[Jeremy Roman]

sgtm

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/71ffbc57-6ffd-431f-bbc6-150ba0d26aac%40chromium.org.

[Chris Blume]

Agreed.
I think the default for most devs is to not even consider it.
People who are considering it likely know what they are doing.

This then leaves a case where someone is looking at unfamiliar code and stumbles across it. Although they may have a "What is this?" moment, that doesn't seem sufficient to warrant banning. I don't think they will end up using it incorrectly.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACuR13daOv1VSwZ713W3cbTyv85Jo6o6ChJZ3WMmD5m_jS%2BfUw%40mail.gmail.com.

[dan...@chromium.org]

+1