On Thu, Oct 13, 2022 at 08:28:52PM +0000, solidstate1991 via Digitalmars-d wrote:
> So I watched this video:
> 
> https://youtu.be/G6b62HmsO6M
> 
> And Walter talked about using operator overloading for nonstandard purposes.
> 
> So in my collections library, I used it to implement set operators, but since set operators don't exist in the D standard (and require unicode, which would upset a lot of people, especially those who don't know what Win + '.' does), I had to use operators that have similar function in other spaces.

I've also written set operators for one of my projects.  I also succumbed to the temptation of overloading bit operators (`|` for set union and `&` for set intersection), because of the obvious analogy to bit vectors.  Originally I wanted to use `+` and `*`, but on second thoughts that's too remote from the usual meaning of + and *, and would make the resulting code too easy to misread, so I settled on | and & instead.  At least the meaning corresponds, if you think of your set in terms of a glorified set of bits indicating the presence/absence of each element.  `*` would be too easy to misunderstand as a Cartesian product in the context of sets.


> I personally haven't used them yet in my projects (except for the unittests), so it's not too late to remove them, but I don't know if anyone else might be using them or not.
> 
> Link to my library with an example offense: https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L356

My personal opinion -- keep | and &, get rid of + and *.


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca

On Fri, Oct 14, 2022 at 02:13:34AM +0000, Mike Parker via Digitalmars-d wrote:
> On Thursday, 13 October 2022 at 21:01:08 UTC, Araq wrote:
> 
> > Before C came along x << y already meant "x is much smaller than y" and x || y sometimes meant "run x and y in parallel". "Nonstandard purposes" hardly means anything. Use the operators as you see fit.
> 
> "nonstandard purposes" were the OP's words, not Walter's. Walter's was talking about overloading for nonarithmetic purposes. This is not an uncommon criticism.

Generally, I agree with Walter.  Operator overloading should not be taken as a free license to bend arithmetic operators to do things alien to their basic arithmetic meaning.  That's just a big code smell, and leads to hard-to-read code with poor maintainability.


> He cited the C++ iostreams library as many who make this criticism do,

Yeah, using << and >> for I/O is a total eyesore. The precedence doesn't make sense for I/O, if you don't parenthesize, the expression could mean something completely different from what you expect.  IMO, this a total code smell, and a symptom of C++'s typical overly-clever-yet-still- incomplete style of addressing language design issues.


> and also a project he saw in the past that overloaded C++ operators to make a regex DSL.
[...]

That would be Boost.Xpressive, I think.  Makes me cringe every time I look at it.  In typical C++ hammer-a-nail-with-a-chainsaw fashion, compile-time regexes take operator overloading abuse to a whole new level and the result looks nothing like a regex, introducing a maintenance nightmare (the same regex gets written in two *completely* different ways depending on whether it's runtime or compile-time -- and good like trying to read the compile-time one).

Now that constexpr is a thing, here's to hoping that this horrendous operator overload abuse will soon be relegated to the dustbin of history.


T

-- 
Caffeine underflow. Brain dumped.

On 10/13/2022 7:44 PM, H. S. Teoh wrote:
>> and also a project he saw in the past that overloaded C++ operators to
>> make a regex DSL.
> [...]
> 
> That would be Boost.Xpressive, I think.

Here it is:

#include <boost/spirit.hpp>
using namespace boost;
int main() {
    spirit::rule<> group, fact, term, expr;
    group   = '(' >> expr >> ')';
    fact    = spirit::int_p   | group;
    term    = fact >> *(('*' >> fact) | ('/' >> fact));
    expr    = term >> *(('+' >> term) | ('-' >> term));
    assert( spirit::parse("2*(3+4)", expr).full );
    assert( ! spirit::parse("2*(3+4", expr).full );
}

https://studylib.net/doc/10029968/text-processing-with-boost---northwest-c---users--group

slide 40

It's a technical marvel, but the embedded DSL looks like C++ expressions yet does something completely different. One cannot distinguish the C++ code from the DSL code. It's in the same category as macros, and I can't recommend it.

On 10/14/2022 12:54 AM, Atila Neves wrote:
> As Bjarne said once in response to complaints that operator overloading lets people write code that doesn't do what you expect:
> 
> ```
> // notice how the code and the docs lie
> /**
>   * Adds two numbers
>   */
> int sum(int i, int j) {
>      return i - j;  // oops
> }
> ```

True that documentation often (always?) lies about what the code actually does. But the causes of this are usually because of programmer laziness and/or error in documenting it correctly.

But operating overloading for non-arithmetic purposes is *deliberately* doing the unexpected.