What about adding keyword forms for some operator symbols, like in C++ ?

Symbol | Keyword
----------------
  !    |   not
  !=   |  noteq
       |
  &&   |   and
  ||   |   or
       |
  &    | bitand
  |    | bitor

Programming languages are evolving, like evolution is evolving.

In 2024 it‘s probably better to support alternative keywords
like ‚or‘, ‚and‘, ‚not‘ additionally to plain symbols like ˋ||ˋ, ˋ&&‘, ˋ!ˋ.

Writing clear code using the english language is better
than using cryptic symbols, in modern times.

On Sunday, 25 February 2024 at 07:42:16 UTC, Danilo wrote:

Quite easy to break existing code in this way. And we're going to add more keywords and "noise".

Andrea

On Sunday, 25 February 2024 at 04:55:08 UTC, Danilo wrote:

Symbol | Keyword
----------------
  !    |   not
  !=   |  noteq
       |
  &&   |   and
  ||   |   or
       |
  &    | bitand
  |    | bitor

Would love to have that. C++ has not, and, and or for a while as keywords.
Makes negations more readable!

On Sunday, 25 February 2024 at 04:55:08 UTC, Danilo wrote:

Symbol | Keyword
----------------
  !    |   not
  !=   |  noteq
       |
  &&   |   and
  ||   |   or
       |
  &    | bitand
  |    | bitor

whats the name of foo["bar",1..5]*=Seq!(13.37,'a');

On Sunday, 25 February 2024 at 15:24:40 UTC, Guillaume Piolat wrote:

Exactly!

Just discovered C++ has keywords 'and'/'or'/'not' etc.
from comments:

Modern C++ : and, or and not as Boolean Operators

Personally I read about it in C++20/23 books round about 2 years ago for updating my C++98 knowledge, and then just started using it. Takes 1-2 days for getting used to it. ;)

On Sunday, 25 February 2024 at 23:40:19 UTC, Danilo wrote:

Adding new ways to do the same is a bad idea.
The problem is not the time to get used to it, this can be negligible small.
The problem is that not everybody is going to use the new way.
So you need to get used to both ways - which creates mental load.
And even worse: you can mix them and so generating differences in the code where there are none. By this way you hide were the important differences are. And that will happen, even if you don't intend to do it.

If you want to create a new language (in this case: using english instead of math symbols), stick to it and don't mix it with the old language.

This of course doesn't apply if you have a new concept not available in a language. Then using a term from another language that better describe it is ok - that's the way languages evolve. But simply adding a new word for the same thing is only useful if you explicitly don't want everybody to understand you. E.g. every new generation invents new words for the same concepts, just to be not understood by their parents. Or some "experts" invent a lot of special terms to not be understood by "ordinary" people.

So if you want to create some elite kind of D, do it on your own fork and don't call it D anymore.

On Sunday, 25 February 2024 at 07:42:16 UTC, Danilo wrote:

I don't consider this an evolution of programming languages. FORTRAN 66 was the first language to have an ANSI standard, and it included these operators, so it's more a recognition that the old guys did it right. COBOL also had them back at least to COBOL 68, (its first standard). Later languages like Lua and Perl have them too.

I'd say at best it's a minor improvement, but it wouldn't have many downsides either.