> However, in C++, '<<' can also mean 'write to standard output'.

This is where I shake off the cobwebs and ancient dust and lost memories from my childhood to point out that I somehow still know that << is the insertion operator. It does more than just write, and it can write to more than just the standard output stream.

https://www.cplusplus.com/reference/ostream/ostream/operator...

However, despite having doubled down on this particular oddity rather than abandoning it as a bad idea in the C++ 11 era, operator<< isn't really "the insertion operator" because you'd obviously give that a different precedence if it existed.

It's an overload for the left shift operator, and keeps the natural precedence of this operator (slightly lower than addition and subtraction) which leads to occasional surprises because something like:

out << x == y;

... is actually outputing x, and then comparing y to the out stream not to x, and then throwing away the result, even though that's clearly not what anybody intended.

"<<"'s meaning in C++ is never "write to standard output". That is the output streams overloading the operator for their own operations. Similarly, you can write operator<< for your classes to mean whatever. The original meaning of "<<" has always been left shift.

I'm not sure what you mean; standard library is part of C++ and it overloaded the meaning in that way. iostream "is C++".

Yep, this blog post is in the context of using these symbols in mathematics, where this is the only usage of << and >> that I've seen.

I agree that programming languages, it can mean various things, just like < and > mean different things in C++ vs bash vs drawing arrows.

If I tell you "Spring was lovely this year" are you going to confuse it with the mechanical part? No.

Context matters.

This is fine in ordinary human conversation because of Grice's maxims and the goal of mutual comprehension, although...

https://www.youtube.com/watch?v=gi_6SaqVQSw

Still you probably don't want opportunities for confusion when dealing with machines. What you are sure is obvious may not be obvious at all to the machine and it needn't care what you thought you meant.

I mean, are we gonna talk about ‘=‘, ‘==‘, and ‘===‘?

Don't forget the languages that use := for assignment! And golang, which I vaguely think can use both = and := to do slightly different assignment (assignment vs initialization?).

Golang uses := to represent declaration and simultaneous assignment to at least one new variable. = only works if the LHS variables have already been declared. If you use :=, at least one of the variables on the LHS has to be new. So the following snippet would be an error:

  a := 3
  ...
  a := 4

This is valid:

  a := 3
  ...
  a = 4

As is this:

  a := 3
  ...
  a, b := 4, 2

And this is an error again:

  a := 3
  b := 4
  a, b := 1, 2

Since neither a nor b are new variables.

As someone who has never used go, the third example feels counter-intuitive to me. I would expect a, b := 4, 2; to be equivalent to a := 4; b := 2; is there a reason it was done this way?

It is as you say, however, a and b had already been declared, which is the error.

But... why the latter?

Because if you're modifying a function and you're adding a new variable to hold some intermediary value, you might accidentally pick a variable name that already exists. If you're in the habit of writing := to signal your intent to create a new variable, that error will probably get caught at compile time rather than being a source of subtle bugs where you trample data needed by something else.

The multi-variable case is trickier, especially because (result, err) is such a common pattern and you neither want to impede the very common case of storing a result into a new variable nor to require a profusion of differently-named variables for errors that are very likely to just get folded anyway. So it allows it if any of the variables are new rather than requiring all. But clearing a large chunk of the bug surface is still much better than not.

(This is only my extrapolated reasoning, of course.)

Oh, this is a good time to remember Prolog exists. Assignment isn't even a concept there, but equality can act on so many different ways!