[JoshTriplett]

You started with "In no language has a variable assignment ever stopped execution", and now you're saying "The assignment operator is not supposed to have side-effects". location.href is a counterexample, and there are many counterexamples throughout various tools and languages and libraries. Deciding how you think things should work does not affect how things do work, and it's important to understand the latter. (I do agree it's bad practice, but it happens and people do not always fully control the environments they must work with.)

And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous.

That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.

[dvt]

> You started with "In no language has a variable assignment ever stopped execution",

The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).

[rowanG077]

The entire discussion is about a property assignment. Which in colloquial usage is also called variable assignment. Which is obvious since nobody corrected you on that. You now trying to do a switcheroo is honestly ridiculous.

[dvt]

The entire discussion is about “=“ doing weird stuff, which in 99.9% of cases it does not do. And my point was that no language, without doing weird stuff (like overloading), does not let “=“ do weird stuff (and thus is pure). The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.

[JoshTriplett]

> The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.

That sounds like a recipe for having problems every time you encounter a nonstandard contract. Are you actually saying you willfully decide never to account for the possibility, or are you conflating "ought not to be" with "isn't"?

If I'm programming in a language that has the possibility of properties, it's absolutely a potential expectation at any time. Which is one reason I don't enjoy programming in such languages as much.

To give a comparable example: if I'm coding in C, "this function might actually be a macro" is always a possibility to be on guard against, if you do anything that could care about the difference (e.g. passing the function's name as a function pointer).

[scheme271]

So, with anything that isn't a primitive type (e.g. int, bool, etc), there's a chance that assignment is going to require memory allocation or something similar. If that's the case then there's a chance of bad things happening (e.g. a out of memory error and the program being killed).

More commonly, if you look at things like c++'s unique_ptr, assignment will do a lot of things in the background in order to keep the unique_ptr properties consistent. Rust and other languages probably do similar things with certain types due to semantic guarantees.

[eru]

In languages like JavaScript (or Python etc) you can get memory allocation etc even when 'primitives' like int and bool are involved.

Haskell is the same, but for different reasons.

[kketch]

Technically no. Producing side effects from a setter is not unexpected, even if it often the best idea to have a setter have a lot of unexpected side effects. However producing side effects from getters is definitely unexpected and should not be done. Interestingly it's one of the areas where rust is really useful, it forces you express your intent in terms of mutability and is able to enforce these expectations we have.

[galangalalgol]

Overloading assignment operators to maintain an invariant is one thing, but this particular case of it running off and effectively doing ionis weird to me coming from an embedded c++ background. I don't like operator overloading and think it should be avoided, just to make my bias obvious. I don't code c++ anymore either, rust and no looking back for a few years now.

[jibal]

But it doesn't run off and do I/O ... that's the bug! The OP assumed that setting the variable causes the new page to be loaded but it doesn't--it just says what page should be loaded. The page doesn't get loaded until the app goes idle. So this whole discussion about setters and side effects is completely off kilter.

[eru]

> Interestingly it's one of the areas where rust is really useful, it forces you express your intent in terms of mutability and is able to enforce these expectations we have.

Though Rust only cares about mutability, it doesn't track whether you are going to launch the nukes or format the hard disk.

[kketch]

True. But I would not expect any programming language to do that.

Rust provides safeguards and helps you to enforce mutability and ownership at the language level, but how you leverage those safeguards is still up to you.

If you really want it you can still get Rust to mutate stuff when you call a non mutable function after all. Like you could kill someone with a paper straw

[eru]

> True. But I would not expect any programming language to do that.

Haskell (and its more research-y brethren) do exactly this. You mark your functions with IO to do IO, or nothing for a pure function.

Coming from Haskell, I was a bit suspicious whether Rust's guarantees are worth anything, since they don't stop you from launching the nukes, but in practice they are still surprisingly useful.

Btw, I think D has an option to mark your functions as 'pure'. Pure functions are allowed internal mutation, but not side effects. This is much more useful than C++'s const. (You can tell that D, just like Rust, was designed by people who set out to avoid and improve on C++'s mistakes.)