That's a nice workaround, but to me that smells like something wrong with the language itself. I can't think of a good reason to allow assignment in an if statement; other than maybe save a few characters and introduce a lot of confusion / bugs in the process. If you need to make an assignment then do it separately, don't hide it in an if statement (imho).
It helps a lot with idiomatic C error handling. You'll often have a function that does something, returns 0 on success, and an error code on error. It's nice to be able to do the assignment in the if statement there.
There's no good reason for it in any language built with exceptions from the ground up, though.
Or with languages that have a better mechanism for returning multiple values. (Passing in pointers to optional results? Ick.)
There's in idiom in Lua to have functions return either <true, result> or <false, error message> (as two arguments, not a tuple) - consequently, it's common to say e.g. "status, f = assert(open_resource(arg, arg2))"; if it fails, the assert will fail, and open_resource will provide the error message.
In statically typed languages, returning a union type (e.g. Error | Pass of Result) also works well. Sometimes exceptions are simpler, sometimes not.
