4 ms·

std::expected is new in C++23, std::from_chars was introduces in C++17. Obviously, 2023 features were not available in 2017. Changing the return type now would

std::expected is new in C++23, std::from_chars was introduces in C++17. Obviously, 2023 features were not available in 2017. Changing the return type now would break everybody's code, with very little benefit, you can easily wrap std::from_chars.

jlarocco 2y ago
Having an inconsistent, special case way of doing something in the name of backwards compatibility is the defining characteristic of C++.
- Night_Thastus 2y ago
  It's a tradeoff. For example: With Python Python breaking changes are more common, and everyone complains about how much they have to go and fix every time something changes. Damned if you do, damned if you don't. Either have good backwards compatibility but sloppy older parts of the language - or have a 'cleaner' overall language at the cost of crushing the community every time you want to change anything.
  - jlarocco 2y ago
    I'm fully aware, just pointing out that C++ is particularly afflicted with backward compatibility issues; far more than other languages. "The Design and Evolution of C++" gives the impression that even back in the 80s, major concessions were being made in the name of compatibility. At that time it was with C; now it's with previous versions of C++.
criddell 2y ago
If returning std::expected makes more sense, why not make it the primary signature and create a wrapper to maintain compatibility with old code?
- Thorrez 2y ago
  Then you would have to use 2 names: the primary name and the wrapper name. What would they be? Using 2 names wastes more of the namespace, and will confuse people. If the wrapper name isn't from_chars, then people's code will break when upgrading.
  - criddell 2y ago
    Oh right. A different return type isn't enough to differentiate one function from another.
cherryteastain 2y ago
They could add an overload like std::expected<T, std::errc> from_chars(std::string_view). That way, since the input arguments are different, there'd be no issues about overload resolution.
- gpderetta 2y ago
  But overloads providing slightly different interfaces are a bane to generic programming. Overloads are already confusing, if they can't be used generically there is really no point in reusing the name.

jlarocco 2y ago

Having an inconsistent, special case way of doing something in the name of backwards compatibility is the defining characteristic of C++.

Night_Thastus 2y ago
It's a tradeoff. For example: With Python Python breaking changes are more common, and everyone complains about how much they have to go and fix every time something changes. Damned if you do, damned if you don't. Either have good backwards compatibility but sloppy older parts of the language - or have a 'cleaner' overall language at the cost of crushing the community every time you want to change anything.
- jlarocco 2y ago
  I'm fully aware, just pointing out that C++ is particularly afflicted with backward compatibility issues; far more than other languages. "The Design and Evolution of C++" gives the impression that even back in the 80s, major concessions were being made in the name of compatibility. At that time it was with C; now it's with previous versions of C++.

criddell 2y ago

If returning std::expected makes more sense, why not make it the primary signature and create a wrapper to maintain compatibility with old code?

Thorrez 2y ago
Then you would have to use 2 names: the primary name and the wrapper name. What would they be? Using 2 names wastes more of the namespace, and will confuse people. If the wrapper name isn't from_chars, then people's code will break when upgrading.
- criddell 2y ago
  Oh right. A different return type isn't enough to differentiate one function from another.

cherryteastain 2y ago

They could add an overload like std::expected<T, std::errc> from_chars(std::string_view). That way, since the input arguments are different, there'd be no issues about overload resolution.

gpderetta 2y ago
But overloads providing slightly different interfaces are a bane to generic programming. Overloads are already confusing, if they can't be used generically there is really no point in reusing the name.