Why overload operators? V would be a second C++ ? Will V still be simple?

[abcxcba]

CHANGELOG.md
V 0.2.2
Overloading of >, <, !=, ==, <= and >= operators.

I think this is a feature that would make the code look confusing.
When looking at other people's code it can make people wonder what "==" means now and if it has been overloaded.
The first word in the introduction of V is "simple", I hope it really is a simple language and not getting more and more complicated and finally becoming C++.

[Delta456]

It is only allowed for structs and type aliases. Operator overloading in V is very limited and restricted, you have to return bool when using these operators.

[nedpals]

Should be moved to discussion instead.

[ntrel]

V already had some operator overloading:
https://github.com/vlang/v/blob/master/doc/docs.md#limited-operator-overloading

[ntrel]

Why overload operators

So we can write generic functions that work whether they are used with built-in types or user defined types.

[abcxcba]

Thanks for all the answers, I agree that operator overloading is useful, but it should be strictly limited, and should be restricted to the language itself, with user customization forbidden, so that the meaning of each operator is made explicit, rather than meaning anything at all.
For example + :
1 + 2 is 3, 'a' + 'b' is 'ab' , all are in line with common sense, but
man and woman are both human beings, but what should man + woman be?
apples and pears are both fruits, what should apples + pears equal?
At this point to know what + will be later you have to look at the code for the overload of "+".

Someone mentioned generic functions, and this is exactly what I was worried about.
I think generic functions are a way to create confusion, defining a generic function may seem simple, but it has the potential to change at any time, and every time you see a "+", I think you should check what it is at that point, not assume it is the same as before, or guess what you think it means.

This is basically impossible to do if you look at the code that implements it every time.
If you don't check it, and assume it's the same as before or guess what it means, then your program may get unpredictable results.
What if its definition changes after a period of use? What happens to the program?

If all the code of the project is written by one person, such a problem seems less fatal.
If more than one person writes the project, over many years, the consequences can be very deadly.

That's what I'm worried about.

Operator overloading is sometimes a good idea.
But if everyone could overload operators, no one would be able to stop its abuse.

[ntrel]

should be restricted to the language itself, with user customization forbidden

Then it's not operator overloading, it's just operators.

[ntrel]

generic functions are a way to create confusion

Modern statically typed programming languages thrive when they have powerful libraries that are efficient, safe, easy to use and expressive. You can't define library container types or library algorithms that satisfy those requirements without good support for generics in the language.

[abcxcba]

should be restricted to the language itself, with user customization forbidden

Then it's not operator overloading, it's just operators.

Yes, my opinion on operator overloading is that it would be better if there were none.

[abcxcba]

Adding more restrictions to the existing :

-, *, /, % : The parameter or the element of the parameter must be a number.

• :
  element of the parameter is :
  number + number return number
  string + string return string
  else return array

Maybe that's better?

[ntrel]

That would be more complicated than what we already have. Whatever the operation:

Both arguments must have the same type

So a numerical type like BigInt (unlimited precision integer) actually can't add a literal number to itself. This simplifies implementation so no method overloads are needed. There is only one operator overload per operation per type. Both operands have to be of the same type.

[abcxcba]

That would be more complicated than what we already have. Whatever the operation:

Both arguments must have the same type

So a numerical type like BigInt (unlimited precision integer) actually can't add a literal number to itself. This simplifies implementation so no method overloads are needed. There is only one operator overload per operation per type. Both operands have to be of the same type.

My idea is that types like "BigInt" should be handled at the language level to minimize the number of operators that can be overloaded, thus reducing the resulting problems.

I think that the "certainty" of the meaning of both functions and operators is the basis for correct results.
Perhaps a single operator overloading implementation for each type would have avoided problem.

Thank you very much for your reply.
V is a language I really like, and I appreciate your contribution to it, and hope to use it in a production environment sooner rather than later.