News for hackers. Stuff that matters.
Re:C++23: The Next C++ Standard by joshuamorton on Tuesday July 11, 2023 @04:20PM (#36686709)
Code is read more often than written. Writing code that can be understood at a glance (by using common, well understood operators) optimizes for readability.

I think your argument is basically "people should not aggressively violate the implicit bonds of interfaces", which is true. But that goes for all interfaces, not just and not in particular those around operators.

We just have cases where it's common with operators because those are one of the few cases where we have lots of things that meet the interface and interact directly as opposed to hierarchically. The same kind of issue comes up with co/contravariant types and containers sometimes, but that's less often visible to end developers.

Re:C++23: The Next C++ Standard by cogman10 on Tuesday July 11, 2023 @06:46PM (#36688257)
I tend to agree with this. I like operator overloading for mathematical constructs (like complex numbers or even just for conversions of literal types, Imagine, for example, you have a gram type and a second type, if you said 1g / 1s you'd get 1gps, that seems reasonable)

I don't like it in the example given

    for (int i : std::views::iota(0, 6)
               | std::views::filter(even)
               | std::views::transform(square))
What benefit does this have over the Javay/Rusty version that looks like this

    for (int i : std::views::iota(0, 6)
               .filter(even)
               .transform(square))
?

No deducing what `|` means, you are applying the filter then transform function against the view.