4 ms·
The majority of time in professional codebases is not spent on typing but reading and understanding code. "saves a bunch of time and makes code way more readab
by fsloth 3y ago
The majority of time in professional codebases is not spent on typing but reading and understanding code.
"saves a bunch of time and makes code way more readable"
Not when everybody defines their own operators.
Note - we are discussing operator overloading, not operators as features in syntax. Operators at the syntax level make life a lot easier. But then everybody uses the exactly same operator semantics, not some weird per-project abstraction.
The lines of code you wrote as an example are not saving anyones time, except when writing it if you are a slow typist and lack a proper IDE support for C++. If typing speed is an issue, get a better IDE, don't write terser code.
- jenadine 3y agoHiding the actual logic in extra boilerplate doesn't make it easier to read. The lines of code in the example save reader's time as they focus attention on the actual business logic. Yes, this assumes that operator overloading follows some convention, but you need to follow conventions regardless to make readable code.
- lost_tourist 3y agoby this reasoning should we get rid of templates/generics as well?
- enriquto 3y agoYES
- woooooo 3y agoMaking things explicit isn't necessarily boilerplate.
- joshuamorton 3y agoCode 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.
- cogman10 3y agoI 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.
- JonChesterfield 3y agoPeople don't use the same operator semantics. Is + commutative? Does it raise exceptions or sometimes return sentinels? What type conversions might == do?
- SubjectToChange 3y agoAnd how exactly do you propose library authors should work with user-defined types? Operator overloading is what allows algorithms to be efficiently generalized across types.