5 ms·

> > a bunch of existing code actively holds and uses multiple mutable references > if a pure function (or block) regards all previously existing memory as one

> > a bunch of existing code actively holds and uses multiple mutable references > if a pure function (or block) regards all previously existing memory as one immutable region Yes, but existing code doesn't do that. So you couldn't leverage this against existing code which is intentionally mutating shared memory. Outside of a rewrite it must continue to do so in order to function. Unless you meant that new functions could be annotated as pure in order to avoid future errors in code not yet written? I'm not so sure a mandatory system would go over well for C++ since many who use it want shared mutability. I'd be fine with an opt-in system of the sort D seems to be headed towards but I'm not really interested in the tight constraints imposed by Rust. I'm not writing OS kernels or crypto routines over here.

verdagon 5y ago
> Unless you meant that new functions could be annotated as pure in order to avoid future errors in code not yet written? Precisely. New functions can be written to treat all pre-existing memory as immutable, and we can be confident that that data won't change. For example, if the pure function sees a unique_ptr<MyThing> somewhere in pre-existing memory, we'll know that that MyThing existed at the time of the pure function call, and will keep existing until the end of the pure function call; nobody can destroy it in-between. Also, it's surprising how many functions in C++ are already effectively pure, and can add the annotation with little (or zero) refactoring. But we don't have to do this, the benefit for new code is enough. > I'm not so sure a mandatory system would go over well for C++ since many who use it want shared mutability This is opt-in; we don't have to annotate all our functions as pure, and we can still use shared mutability freely outside of pure functions. We can then hand a shared-mutable blob of data to a pure function, which will then treat it as a shared-immutable blob of data. That's why I like this approach: one can write an entire program without it, and one can start using it whenever they want. It composes well like that. Also, if one wants to leverage the region borrow checker outside of pure functions, that's possible too. In Vale, even when not in pure functions, one would make use of `iso` objects (little isolated sub-regions in an otherwise shared-mutable region, similar to Pony's `iso`) and treat those as immutable or mutable as one desires. I suspect it could work in C++ too, but nobody's tried it so I can't say for certain.
- fivea 5y ago
  > Precisely. New functions can be written to treat all pre-existing memory as immutable, and we can be confident that that data won't change. Isn't that the point of const?
  - ender341341 5y ago
    no, `const` means you can't modify the data through that `const` variable (excepting shenanigans), not that it's immutable. It can be rather confusing.
    - fivea 5y ago
      > no, `const` means you can't modify the data through that `const` variable (excepting shenanigans), not that it's immutable. But that's the whole point, isn't it? I mean the selling point of these lifetime annotations is to allow developers to specify that data within a thread cannot be modified by the code running in that thread. Isn't that exactly what const does?
      - flqn 5y ago
        No, const can be added to objects at any declaration or callsite, meaning there can be many const- and non-const references to the same object within the same scope/thread/program/address space/execution context. Const doesn't solve aliasing.
        fivea 5y ago
        I think you are discussing different things, and in the process missing the whole point. It's one thing for an object to be immutable throughout is life cycle. That's immaterial to this discussion. It's an entirely different thing that the same object cannot be changed within specific contexts. If you want to ensure that a thread has read access to an object and it cannot be changed accidentally then passing a const reference to that object already ensures that. That's pretty much the whole point of const.

verdagon 5y ago

> Unless you meant that new functions could be annotated as pure in order to avoid future errors in code not yet written? Precisely. New functions can be written to treat all pre-existing memory as immutable, and we can be confident that that data won't change. For example, if the pure function sees a unique_ptr<MyThing> somewhere in pre-existing memory, we'll know that that MyThing existed at the time of the pure function call, and will keep existing until the end of the pure function call; nobody can destroy it in-between. Also, it's surprising how many functions in C++ are already effectively pure, and can add the annotation with little (or zero) refactoring. But we don't have to do this, the benefit for new code is enough. > I'm not so sure a mandatory system would go over well for C++ since many who use it want shared mutability This is opt-in; we don't have to annotate all our functions as pure, and we can still use shared mutability freely outside of pure functions. We can then hand a shared-mutable blob of data to a pure function, which will then treat it as a shared-immutable blob of data. That's why I like this approach: one can write an entire program without it, and one can start using it whenever they want. It composes well like that. Also, if one wants to leverage the region borrow checker outside of pure functions, that's possible too. In Vale, even when not in pure functions, one would make use of `iso` objects (little isolated sub-regions in an otherwise shared-mutable region, similar to Pony's `iso`) and treat those as immutable or mutable as one desires. I suspect it could work in C++ too, but nobody's tried it so I can't say for certain.

fivea 5y ago
> Precisely. New functions can be written to treat all pre-existing memory as immutable, and we can be confident that that data won't change. Isn't that the point of const?
- ender341341 5y ago
  no, `const` means you can't modify the data through that `const` variable (excepting shenanigans), not that it's immutable. It can be rather confusing.
  - fivea 5y ago
    > no, `const` means you can't modify the data through that `const` variable (excepting shenanigans), not that it's immutable. But that's the whole point, isn't it? I mean the selling point of these lifetime annotations is to allow developers to specify that data within a thread cannot be modified by the code running in that thread. Isn't that exactly what const does?
    - flqn 5y ago
      No, const can be added to objects at any declaration or callsite, meaning there can be many const- and non-const references to the same object within the same scope/thread/program/address space/execution context. Const doesn't solve aliasing.
      - fivea 5y ago
        I think you are discussing different things, and in the process missing the whole point. It's one thing for an object to be immutable throughout is life cycle. That's immaterial to this discussion. It's an entirely different thing that the same object cannot be changed within specific contexts. If you want to ensure that a thread has read access to an object and it cannot be changed accidentally then passing a const reference to that object already ensures that. That's pretty much the whole point of const.