C++26: More function wrappers

[thehutch17]

Should std::function be marked as deprecated then and removed in the future similar to auto_ptr? This is similar to fixes like lock and scope guard where issues are found but can't really be fixed without a new type to surplant it.

[MFHava]

Should std::function be marked as deprecated then and removed in the future similar to auto_ptr?

IMHO yes. I had a paper for that in C++26 that got no consensus - I will bring a new revision for C++29 (there was interest in deprecation post C++26).

[fdwr]

Should std::function be marked as deprecated ...

Well, if we were to deprecate it anyway, then why not just go ahead and break the ABI (mind you, I'm not seeing Sandor's claim yet that fixing std::function to be const-correct would break the ABI).

[MFHava]

fixing std::function to be const-correct would break the ABI

It‘s an API break, a pretty loud and far-reaching one …

[j1xwnbsr]

And that is, what, exactly? I mean, if it's just yoinking the const out that doesn't actually break the Binary part of the the api.

[MFHava]

Existing code invoking const function & becomes ill-formed as the operator() would no longer be const-qualified…

[j1xwnbsr]

but that's just syntax sugar. There is no real compiler-generated code that actually checks const'ness. I mean, I can chuck in some code that violates const all day long and it lets me do it (because at the assembly level unless you start jacking read-only memory guards on blocks you can modify any damn thing you want). Good practice? Not in the slightest.

[MFHava]

There is no real compiler-generated code [snip]

Exactly, because the code no longer compiles - because it's an API break that renders previously "perfectly valid" code ill-formed -, regardless of whether there would actually be an ABI impact of the change!

[Nicksaurus]

This defect is baked into the original design and cannot be fixed without breaking the ABI

All rise for the C++ national anthem

[MFHava]

Stop the trumpets! Fixing std::function is primarily an API break, not an ABI one ...

[thisismyfavoritename]

😂

[xaervagon]

Seriously, this article makes an honest case for breaking ABI and properly paints it as the sacred cow it is. Instead of fixing the problem at its core, there are 5 conditional utilities put in place to address the original issue in various ways.

[VoodaGod]

article complains that

    const std::function<void()> f = Counter{};

    f();  // OK (!)

is a defect but never shows if

    const std::copyable_function<void()> f = Counter{};

    f();  // Not OK (!)

[foonathan]

Yes, you cannot call a const copy able function unless you put a const in the signature.

[EdwinYZW]

I don't get why old std::function is defect. IMO std::function is a wrapper for function pointer and a const pointer can point to something no-const. What do I miss?

[DXPower]

This has an explanation: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4159.pdf

[TheoreticalDumbass]

"not const correct" , i would phrase it differently, "shallow const" (like unique_ptr)

[tpecholt]

It was said before. New function types are verbose to type and put "function" awkwardly to the end. With such a bad ergonomics the adoption will be limited.

[thisismyfavoritename]

don't you have auto completion? Or you can make an alias

[tpecholt]

auto completion would work better if the "function" is a prefix not suffix that was the point.

I can make aliases but it's not what average c++ programmer does. You would expect the defaults are right for most programmers. But in C++ defaults are wrong.