Usage of keywords like eq and lt/gt as more ergonomic alternatives to == and < or >

[mahmoud-moursy]

This was a feature that used to exist in C++ that allowed you to use English words as alternative operators to things like ==, != and <.

The feature was brought to life due to technological restrictions, where certain encodings didn't have characters like =, & or ^... but it made me curious about the semantics of such syntax. Looking at it, it doesn't seem too terrible, and in my opinion it might even look slightly better (depending on the circumstances). This is what I'd imagine the pseudocode would look like.

import Console;

fn Main() -> i32 {
  if(2 eq 2) {
    Console.Print("Hello world!");
  }

  if(2 gt 2) {
    Console.Print("I will never print out because 2 is not greater than 2.");
  }

  if(false or true) {
    Console.Print("I will always print out!");
  }

  return 0;
}

I have two big problems with this.

Firstly, it introduces two ways to write code which I am pretty sure everybody hates and everybody wants to avoid.

Secondly, while I believe that keywords are more ergonomic than symbols, the semantics of this come into question once it starts to conflict with English grammar. For example, look at the following pseudocode:

// This is assuming that ints can be implicitly cast to bools.
// I am not entirely sure if this is possible in Carbon and I couldn't check,
// but I am sure that this could apply to other scenarios.
fn Main() -> i32 {
  // Should it be true? Should it be false? Nobody knows!
  if(0 eq 3 or 0) {
    Console.Print("I am very confused.");
  }

  // Perhaps a case like this is more applicable?
  false eq true or false;

  return 0;
}

If we were to somehow figure out all of these and add it, I'd also consider extending it further than C++ did with some additional keywords like not, as a replacement to !.

[L4stR1t3s]

I find that keywords make it harder to visually parse a line of code, than symbols:
if (something eq this or that) { print( this and that ); }
if (something == this || that) { print( this && that ); }
Keywords use the same characters as types, variables, functions, ... which makes it much harder to distinguish between them at a quick glance. I prefer readability over ergonomics.

[YagaoDirac]

I voted no. But no matter which is selected, it's ok for me.
Also, I would like to say, when we design these syntax, we should not limit the design on character, text. IDE can provide a lot display sugar, but for now only very little such display suger in IDE is invented.
None of == or eq is more readable than an icon.
So, my suggestion is that, the specification should include what IDE needs to do.

[L4stR1t3s]

So, my suggestion is that, the specification should include what IDE needs to do.

Different people have different preferences. I personally would absolutely hate seeing icons in my code instead of characters. But if you like it, then I have no problem with you replacing characters with icons. IDEs are reflections of personal preferences, not a reflection of a global standard.

[YagaoDirac]

It's not personal preference. It's readability. I read all the =, ==, eq, &&, and, without any obstacles.