Technically, some syntactic sugar can be worth keeping even if it can trivially be replaced, if it improves readability of some common operation.
But assignment-as-expression does not fall under that. The danger of typo-ing it in place of a comparison means it’s rarely used (sometimes even prohibited by style guides) and provokes a double take whenever it is used. In other words, the readability benefits are small in number and magnitude.

A look at existing languages that do this may be worthwhile.

• Java and C# keep assignment an expression but remove the pitfall you mention by requiring conditions to evaluate to booleans. This mostly seems to work well, though people occasionally complain that this disallows conditions like if (x) in place of if (x != null) or if (x != 0) depending on the type of x.
• Python makes assignment a proper statement instead of an expression. Proposals for changing this occasionally reach the python-ideas mailing list, but my subjective impression is that this happens more rarely and generates less noise each time compared to other “missing” features like do-while loops, switch statements, multi-line lambdas, etc.

However, Python allows one special case, assigning to multiple names at once: a = b = c. This is considered a statement equivalent to b = c; a = b, and it’s occasionally used, so it may be worth adding to your language as well (but I wouldn’t sweat it, since this addition should be backwards-compatible).

Are there any practical uses of the assignment operator’s return value that could not be trivially rewritten?

Generally speaking, no. The idea of having the value of an assignment expression be the value that was assigned means that we have an expression which may be used for both its side effect and its value, and that is considered by many to be confusing.

Common usages are typically to make expressions compact:

x = y = z;

has the semantics in C# of “convert z to the type of y, assign the converted value to y, the converted value is the value of the expression, convert that to the type of x, assign to x”.

But we are already in the realm of impertative side effects in a statement context, so there’s really very little compelling benefit to that over

y = z;
x = y;

Similarly with

M(x = 123);

being a shorthand for

x = 123;
M(x);

Again, in the original code we are using an expression both for its side effects and its value, and we are making a statement that has two side effects instead of one. Both are smelly; try to have one side effect per statement, and use expressions for their values, not for their side effects.

I’m developing a language which I intend to replace both Javascript and PHP.

If you really want to be bold and emphasize that assignment is a statement and not an equality, then my advice is: make it clearly an assignment statement.

let x be 1;

There, done. Or

x <-- 1;

or even better:

1 --> x;

Or even better still

1 → x;

There’s absolutely no way that any of those are going to be confused with x == 1.

Many languages do choose the route of making assignment a statement rather than an expression, including Python:

foo = 42 # works
if foo = 42: print "hi" # dies
bar(foo = 42) # keyword arg

and Golang:

var foo int
foo = 42 # works
if foo = 42 { fmt.Printn("hi") } # dies

Other languages don’t have assignment, but rather scoped bindings, e.g. OCaml:

let foo = 42 in
  if foo = 42 then
    print_string "hi"

However, let is an expression itself.

The advantage of allowing assignment is that we can directly check the return value of a function inside the conditional, e.g. in this Perl snippet:

if (my $result = some_computation()) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}

Perl additionally scopes the declaration to that conditional only, which makes it very useful. It will also warn if you assign inside a conditional without declaring a new variable there – if ($foo = $bar) will warn, if (my $foo = $bar) will not.

Making the assignment in another statement is usually sufficient, but can bring scoping problems:

my $result = some_computation()
if ($result) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}
# $result is still visible here - eek!

Golang heavily relies on return values for error checking. It therefore allows a conditional to take an initialization statement:

if result, err := some_computation(); err != nil {
  fmt.Printf("Failed with %d", result)
}
fmt.Printf("We succeeded, and the result is %dn", result)

Other languages use a type system to disallow non-boolean expressions inside a conditional:

int foo;
if (foo = bar()) // Java does not like this

Of course that fails when using a function that returns a boolean.

We now have seen different mechanisms to defend against accidental assignment:

• Disallow assignment as an expression
• Use static type checking
• Assignment doesn’t exist, we only have let bindings
• Allow an initialization statement, disallow assignment otherwise
• Disallow assignment inside a conditional without declaration

I’ve ranked them in order of ascending preference – assignments inside expressions can be useful (and it’s simple to circumvent Python’s problems by having an explicit declaration syntax, and a different named argument syntax). But it’s ok to disallow them, as there are many other options to the same effect.

Bug-free code is more important than terse code.

You said “I figured (with little evidence beyond my personal experience) that the vast majority of times this happened, it was really intended to be comparison operation.”

Why not FIX THE PROBLEM?

Instead of = for assignment and == for equality test, why not use := for assignment and = (or even ==) for equality?

Observe:

if (a=foo(bar)) {}  // obviously equality
if (a := foo(bar)) { do something with a } // obviously assignment

If you want to make it harder for the programmer to mistake assignment for equality, then make it harder.

At the same time, if you REALLY wanted to fix the problem, you would remove the C crock that claimed booleans were just integers with predefined symbolic sugar names. Make them a different type altogether. Then, instead of saying

int a = some_value();
if (a) {}

you force the programmer to write:

int a = some_value();
if (a /= 0) {} // Note that /= means 'not equal'.  This is your Ada lesson for today.

The fact is that assignment-as-an-operator is a very useful construct. We didn’t eliminate razor blades because some people cut themselves. Instead, King Gillette invented the safety razor.

To actually answer the question, yes there are numerous uses of this although they are slightly niche.

For example in Java:

while ((Object ob = x.next()) != null) {
    // This will loop through calling next() until it returns null
    // The value of the returned object is available as ob within the loop
}

The alternative without using the embedded assignment requires the ob defined outside the scope of the loop and two separate code locations that call x.next().

It’s already been mentioned that you can assign multiple variables in one step.

x = y = z = 3;

This sort of thing is the most common use, but creative programmers will always come up with more.

Since you get to make up all the rules, why now allow assignment to turn a value, and simply not allow assignments inside conditional steps? This gives you the syntactic sugar to make initializations easy, while still preventing a common coding mistake.

In other words, make this legal:

a=b=c=0;

But make this illegal:

if (a=b) ...

By the sounds of it, you are on the path of creating a fairly strict language.

With that in mind, forcing people to write:

a=c;
b=c;

instead of:

a=b=c;

might seem an improvement to prevent people from doing:

if (a=b) {

when they meant to do:

if (a==b) {

but in the end, this kind of errors are easy to detect and warn about whether or not they are legal code.

However, there are situations where doing:

a=c;
b=c;

does not mean that

if (a==b) {

will be true.

If c is actually a function c() then it could return different results each time it is called. (it might also be computationally expensive too…)

Likewise if c is a pointer to memory mapped hardware, then

a=*c;
b=*c;

are both likely to be different, and also may also have electronic effects on the hardware on each read.

There are plenty of other permutations with hardware where you need to be precise about what memory addresses are read from, written to and under specific timing constraints, where doing multiple assignments on the same line is quick, simple and obvious, without the timing risks that temporary variables introduce

The greatest benefit to my mind of having assignment be an expression is that it allows your grammar to be simpler if one of your goals is that “everything is an expression”–a goal of LISP in particular.

Python does not have this; it has expressions and statements, assignment being a statement. But because Python defines a lambda form as being a single parameterized expression, that means you can’t assign variables inside a lambda. This is inconvenient at times, but not a critical issue, and it’s about the only downside in my experience to having assignment be a statement in Python.

One way to allow assignment, or rather the effect of assignment, to be an expression without introducing the potential for if(x=1) accidents that C has is to use a LISP-like let construct, such as (let ((x 2) (y 3)) (+ x y)) which might in your language evaluate as 5. Using let this way need not technically be assignment at all in your language, if you define let as creating a lexical scope. Defined that way, a let construct could be compiled the same way as constructing and calling a nested closure function with arguments.

On the other hand, if you are simply concerned with the if(x=1) case, but want assignment to be an expression as in C, maybe just choosing different tokens will suffice. Assignment: x := 1 or x <- 1. Comparison: x == 1. Syntax error: x = 1.

I know that this would mean that those one-line functions that C people love so much would no longer work. I figured (with little evidence beyond my personal experience) that the vast majority of times this happened, it was really intended to be comparison operation.

Indeed. This is nothing new, all the safe subsets of the C language have already made this conclusion.

MISRA-C, CERT-C and so on all ban assignment inside conditions, simply because it is dangerous.

There exists no case where code relying on assignment inside conditions cannot be rewritten.

Furthermore, such standards also warns against writing code that relies on the order of evaluation. Multiple assignments on one single row x=y=z; is such a case. If a row with multiple assignments contains side effects (calling functions, accessing volatile variables etc), you cannot know which side effect that will occur first.

There are no sequence points between the evaluation of the operands. So we cannot know whether the subexpression y gets evaluated before or after z: it is unspecified behavior in C. Thus such code is potentially unreliable, non-portable and non-conformant to the mentioned safe subsets of C.

The solution would have been to replace the code with y=z; x=y;. This adds a sequence point and guarantees the order of evaluation.

So based on all the problems this caused in C, any modern language would do well to both ban assignment inside conditions, as well as multiple assignments on one single row.