= for assignment and == for equality is confusing

[Alex-Costea]

I think it's a bad C/C++ design decision that shouldn't keep being replicated in a new language with improved syntax.

• = for assignment is confusing, especially for people with a mathematics background. It implies equality but is assignment
• == as a repeated symbol operator is ugly. This is subjective, but needing a second equals for equality is unpleasant
• = / == lead to confusion between equality and assignment in statements such as if(a=b)
• I believe = should be equality, just like in non-programming usage, and assignment can be <- or :=

This is just my opinion and I realise the language designers have already considered this issue. I just wish to make the case for it. There is no reason to keep replicating the somewhat awkward C++ syntax in a new language. It would reduce some of the difficulty for programming beginners while experienced C++ programmers can adapt quickly to a slight improvement of syntax.

[alloncm]

Those are interesting ideas but in my opinion Carbon is not the place to try or consider them, Carbon's goal is to be a good successor to C++, not reinvent the way we programmers program and make it more consistent with the way mathematics behaves semantically.

In my opinion those ideas deserve more attention, just not as part of the Carbon project.

[EdwardStables]

Even mathematically focused languages like Matlab and Julia use C-style = and ==. These usages are pretty ingrained at this point.

[jmccabe]

My understanding of the point of carbon is to create a safer, and more sensible version of C++, with interoperability.

The former has existed since the early 80s, and is called Ada. Ada will interface with C and C++ code by default, but the reverse is not true. Ada's syntax and semantics were designed, in depth, not just 'knocked up', to overcome many of the issues that arose because of the poor design of C syntax, most of which has been inherited by C++, and much of it in Java and other languages.

How "we programmers program", if you're suggesting C++ syntax is 'the norm', is really pretty poor and any organisation that believes C++ syntax is a good starting point for a new language, just because it's what lots of people know, really should not be taken seriously.

Their starting point should be the steelman version of the requirements for the Ada language.

[srohatgi01]

These are indeed good points but as @alloncm said these are not the right place to consider them. Moreover most of the programmers are going to have experience with C++ and most of the programmers are comfortable with the current syntax of equality and comparison.

Changing it in the Carbon will introduce a lot of confusion.

[jmccabe]

Nearly every programmer who has used C and/or C++ and/or numerous other languages that follow this nonsensical syntax will have been stung by the mistake. There are multiple solutions to the problem, but the most sensible, and reliable one is to NOT use = on its own for assignment.

If Google really wants their language to be taken seriously, they need to do something about the problems inherent in C and C++ syntax, not just follow the herd 'because that's what people are used to'. The latter is not language design; it's hacking.

[MichaelBonnet]

I remain a fierce proponent of the walrus operator for assignment.

[marcauberer]

Apart from what the others already have pointed out, this would probably result in difficulties while parsing. What you would need to do here, is essentially push the decision whether you have a comparison or an assignment from the tokenizing step to the semantic analysis.
I could imagine that this makes it harder to implement.

Using a different token for the assignment would be not a problem in this regard though.

[jmccabe]

If you're going to use implementation difficulty, at the compiler level, as the main driver for whether a feature that improves clarity, safety and reliability is adopted, then you may as well abandon the project now as you will be doing nothing to avoid the technical debt issues that the language announcement claimed were inherent in C++. The GCC compiler suite includes support for Ada, which already supports a huge number of features that are more reliable, safer, easier to use and just as performant as C++; look at those sources for solutions; they've been around for 40 years.

[marcauberer]

What I am trying to say is, in addition what the others said, this could make the compilation process slower and more complicated. Carbon wants to be a successor for C++, so we need to have performance aspects in view and have to discuss them as well. (Especially compile time performance in my opinion, since it sucks in C++)

[jmccabe]

One of the primary causes of C++ compilation taking a long time has been the reliance on the textual inclusion of header files. This issue has already been addressed in a multitude of other languages over the years, including Ada and, now C++ through the inclusion of the module system.

One of the drivers of "fast compilation times" is to speed up the build/run/debug/fix cycle; numerous aspects of the C++ language design (and C), due to their unsafe and unreliable nature (complicated and inconsistent syntax, implicit conversions) have contributed to the number of times round that cycle being higher than is necessary with some languages that, although they take a little longer to compile, are more likely to work as expected once they do compile.

In an ideal world, a compilers is written once; including safe and consistent features in a language syntax may cause minor additional difficulties in the creation of compilers for that language (indeed, early Ada compilers suffered with this but, over time, have become very good), however doing that once saves time for ALL of the developers who're going to be using the language. In other words, don't impose a need for many, many developers to spend time creating work-arounds to language inadequacies that, with a little extra up-front effort, could be solved in the compiler. Clearly, however, features that are nigh-on impossible to implement in a compiler should be avoided, but ones that just take a little more time not so.

In summary, what I'm trying to say is learn from the mistakes of the past (including the mistakes made in the design of Ada!); don't compromise safety, readability and syntactical consistency just because it may take a few extra ms to compile.

If Carbon really wants to be a successor to C++, it needs to address the fundamental flaws in C++ syntax, not blindly accept them.

However I've made a comment elsewhere that I'm going to step back from further discussion on Carbon; I may continue to respond to the ones I've already commented on, but I'm not going to get involved in any other discussions. Sorry, but that's primarily because what I've read so far has not convinced me that the approach being taken is appropriate.

[nacaclanga]

The real flaw in C++, is not the = vs == syntax, but the fact that = returns a value, that can be used in a conditional expression. The return value of an assignment is rarely used, so just defining the return value of an assignment expression to be the void type and not allowing it as a conditional expression turns 99% of incorrect uses into compile errors. Incorrectly using == when an assignment is desired could exist, but rarely occurs in practice.
If = is chosen as equality only and := or <- for assignment, this introduces a high risk that a habitual programmers accidentally uses = when an assignment is desired, which will not result in a compile error, hence this option will IMO just move from one problem to another.
The last option is to use == for equality and := or <- for assignment. This will catch all accidentally uses at the expense of increasing their likelihood to appear, so IMO this is also not an improvement.

[vbregier]

I agree with first statement.
An assignment should not return a value, this is a C flaw that should be fixed in carbon.
This was done to support assigning multiple variables to same value
int a,b,c; a = b = c = 1;
which is very rarely needed, and a bad way to write things anyways.

[Wajinn]

The last option is to use == for equality and := or <- for assignment. This will catch all accidentally uses at the expense of increasing their likelihood to appear, so IMO this is also not an improvement.

I strongly disagree about this, as the walrus operator (:=) is used in several languages and it works very well. Even Python finally got the clue, and introduced the walrus. Other languages that use it: Smalltalk, Eiffel, Golang, Jai, Vlang, Odin...

Using == for equality (along with := for assignment), is debatably an acceptable to even good idea, as you now have more operators so that which ones are doing what is more visually clear.

[Wajinn]

= for assignment is confusing, especially for people with a mathematics background. It implies equality...
.. I believe = should be equality, just like in non-programming usage, and assignment can be <- or :=

I agree with some of Alex's statements. It makes more sense to have := for assignment, and several other languages have figured this out and use the walrus operator for at least assignment, and things have worked out fine. The world didn't stop spinning, by changing direction.

This issue is debatably more a matter of following a knowingly flawed tradition of using = for assignment. If one is creating a new programming language, that is a golden opportunity to do things right or better. I guess we will see which wins out in this case.

[Tomttth]

= and == are pretty much known by everyone. It would be best to keep the same two operators. One thing I would like to add is not add another === operator like in javascript to the mix as it can be pretty confusing to new programmers. It would be good to have a function instead of this.

[HudsonLSchumaker]

I am sorry, but this don't make sense for me, due all the previous experiences of programming languages are this way:
= for assignment
== assignment

change this will confuse many developers.