by akling on 4/2/22, 1:35 PM with 111 comments
by verdagon on 4/2/22, 4:22 PM
This is actually possible for C++, if we add a concept of pure functions: functions that don't modify anything indirectly reachable from arguments (or globals). Basically:
* Annotate those parameters as "immutable" or as coming from the same immutable "region". Anything reached through them would also have that immutable annotation.
* Anything created during the call would not have that annotation.
The type system, basically a borrow checker, could keep them separate and make sure we don't modify anything that came from outside the function.
We're currently adding this to Vale [0], It's a way to blend shared mutability with borrow checking, and it gives us the optimization power and memory safety of borrow checking without all the constraints and learning curve problems.
[0]: https://verdagon.dev/blog/seamless-fearless-structured-concu...
by htfy96 on 4/2/22, 4:39 PM
An example: https://github.com/llvm/llvm-project/blob/main/clang/test/Se...
More details can be found at https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
Unfortunately it was never upstreamed according to https://github.com/mgehre/llvm-project/issues/98
by benreesman on 4/2/22, 5:29 PM
I’m grudgingly coming around to the idea that Rust is probably a rock-solid FFI story away from being a serious part of my kit (pybind11 good, not like anything we have now).
But there is this in-between place where first-class linear/affine typing could be bootstrapped off of move semantics.
by summerlight on 4/2/22, 6:20 PM
by westurner on 4/2/22, 3:21 PM
> We are designing, implementing, and evaluating an attribute-based annotation scheme for C++ that describes object lifetime contracts. It allows relatively cheap, scalable, local static analysis to find many common cases of heap-use-after-free and stack-use-after-return bugs. It allows other static analysis algorithms to be less conservative in their modeling of the C++ object graph and potential mutations done to it. Lifetime annotations also enable better C++/Rust and C++/Swift interoperability.
> This annotation scheme is inspired by Rust lifetimes, but it is adapted to C++ so that it can be incrementally rolled out to existing C++ codebases. Furthermore, the annotations can be automatically added to an existing codebase by a tool that infers the annotations based on the current behavior of each function’s implementation.
> Clang has existing features for detecting lifetime bugs [...]
by StillBored on 4/3/22, 1:50 AM
I've not generally been a big fan of where C++ has been going in the last couple revisions, mostly because it seems the newer features aren't fully thought out when it comes to how they interact with other features (reminds me of javascript in that regard) leaving a bunch of new footguns, looks at lambda's.
I think i've said this here before, that C++ needs its own version of "use strict;" that basically kills off some of the syntactically odd corner cases that lead to those footguns.
by c0balt on 4/2/22, 3:40 PM
by tialaramex on 4/2/22, 5:36 PM
> If there are multiple input lifetimes but one of them applies to the implicit this parameter, that lifetime is assigned to all elided output lifetimes.
In Rust we have self rather than this in methods, but importantly we sometimes don't take a reference here, and that's still a method, and you still have the self parameter, but the lifetime elision rules don't apply. They don't apply because if you've actually got self, not some reference to self, the lifetime of self is going to end when the function finishes, so returning things with that lifetime is nonsense.
This can make sense in Rust for transformative methods. If there's a method on a God that turns them into a Mortal, the God doesn't exist any more when that method exits, the Mortal is the return type, and if you just drop it then I guess sucks to be them. (In Rust, and I think in C++ you can label something as must-use and cause a warning or error if the programmer forgets to use it).
It seems though, as if this C++ rule would hit such methods too. Can you distinguish in C++ between "a reference to me" and "me" when it comes to methods? If you had a method on a God class in C++ that transforms the God into a Mortal and returns the Mortal, what does that look like? Does this elision rule make sense to you for such a scenario?
by malkia on 4/2/22, 6:04 PM
by queuebert on 4/3/22, 1:31 AM
by lamp987 on 4/2/22, 4:24 PM
but maybe thats how we'll finally get rid of c++.
by aaaaaaaaaaab on 4/2/22, 6:51 PM
by 323 on 4/2/22, 5:52 PM
by kjksf on 4/2/22, 3:43 PM