3 ms·

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. H

by kketch 1y ago

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 1y ago
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 1y ago
  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 1y ago
> 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 1y ago
  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 1y ago
    > 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.)

by kketch 1y ago

galangalalgol 1y ago

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 1y ago
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 1y ago

> 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 1y ago
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 1y ago
  > 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.)