Proposal: allow static operators () and []

[Victor Vianna]

This affects many functors. One example from //ash.

```

struct Compare {

  bool operator()(const AcceleratorData& lhs,
                           const AcceleratorData& rhs) {
    return std::tie(lhs.trigger_on_press, lhs.keycode, lhs.modifiers) <
           std::tie(rhs.trigger_on_press, rhs.keycode, rhs.modifiers);
  }
};

```

Before C++23, the method above cannot be marked static, so every call (in principle) includes an unused `this` pointer.  From what I read, the compiler may be smart and optimize the parameter away, but that's not guaranteed. Marking the method as static guarantees better performance and code clarity. I propose we allow this feature and migrate existing uses.

[Avi Drissman]

SGTM. Tiny performance wins are still wins, and the fewer exceptions to "everything is allowed", the better.

Avi

--
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 view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CANFyMwwaE9dvfyXM6CbkuT9Q0Div3hUTXHRwLMGomR%2BrK4m-KA%40mail.gmail.com.

[Elly]

I approve!

-- elly

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAaOKN_x1LcOVgmE5aEA3cJ3oVn4F6p62pAbDFKvz-zzZg%40mail.gmail.com.

[Jan Wilken Dörrie]

LGTM.

> I propose we allow this feature and migrate existing uses.

Note that this feature also applies to capture-less lambdas. All of those could be made static, too. This wasn't done by default, since it would break existing code, as explained in the proposal. Do you intend to migrate those too? I probably wouldn't, as the added noise is substantial here and I trust compilers to optimize lambdas.

Regardless, we should also update `base::BindOnce` and friends to support functors with static call operator.

[Victor Vianna]

> From what I read, the compiler may be smart and optimize the parameter away, but that's not guaranteed. Marking the method as static guarantees better performance and code clarity.

Quick update: Jan's reply prompted me to try to analyze if crrev.com/c/7481309 brings any perf diff at all when compiling with -O2. I'm still figuring out the correct incantation of -fsave-optimization-record + llvm-remarkutil but preliminary findings show that this change is probably not worth the churn. So I'll likely just drop it.

> Note that this feature also applies to capture-less lambdas. All of those could be made static, too. This wasn't done by default, since it would break existing code, as explained in the proposal. Do you intend to migrate those too? I probably wouldn't, as the added noise is substantial here and I trust compilers to optimize lambdas.

Thanks, I didn't know about the static lambdas. Yeah, there are too many lambdas in chromium, unless there is a huge benefit we shouldn't migrate.

> Regardless, we should also update `base::BindOnce` and friends to support functors with static call operator.

This part is done.

[Joe Mason]

On Tue, Jan 20, 2026 at 8:15 PM 'Victor Vianna' via cxx <c...@chromium.org> wrote:

> From what I read, the compiler may be smart and optimize the parameter away, but that's not guaranteed. Marking the method as static guarantees better performance and code clarity.

Quick update: Jan's reply prompted me to try to analyze if crrev.com/c/7481309 brings any perf diff at all when compiling with -O2. I'm still figuring out the correct incantation of -fsave-optimization-record + llvm-remarkutil but preliminary findings show that this change is probably not worth the churn. So I'll likely just drop it.

The results would be invalid without PGO anyway. +1 on allowing the static operators for future code, but not updating existing ones unless profiling's shown them to be a bottleneck.

Note that if a comparison operator for a btree map/set is a bottleneck, switching to absl::flat_hash_map / absl::flat_hash_set would likely be a better improvement in most cases anyway.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/8a95dca7-7248-468f-9e9f-34c309e5769bn%40chromium.org.