6 ms·

At this year's CppCon Herb Sutter the chair of the ISO C++ committee addressed just this issue of lifetime safety. Here is a video of his talk and includes a de

At this year's CppCon Herb Sutter the chair of the ISO C++ committee addressed just this issue of lifetime safety. Here is a video of his talk and includes a demo of the upcoming static analysis tool that can do this with very minimal annotations https://m.youtube.com/watch?v=hEx5DNLWGgA https://m.youtube.com/watch?v=hEx5DNLWGgA I remember thinking when watching the talk that this was a very bad day for Rust as C++ could now do most of what Rust was promising

pcwalton 11y ago
The lifetime stuff in C++ is full of annotations, with effectively just as many required as Rust. I think of it effectively as a separate language. It's also significantly more complex, with points-to analysis instead of inherited mutability, and the restrictions on pointer aliasing on function entry seem very restrictive compared to what RefCell provides. I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.
- pjmlp 11y ago
  The danger here to Rust is the usual "worse is better". OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it. Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries. Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes. Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
  - pcwalton 11y ago
    > Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. > Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role. And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused. By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.
    - pjmlp 11y ago
      > Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. Have you spent any time reading Apple documentation? https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Swift is a successor to both the C and Objective-C languages." Mesa/Cedar at Xerox PARC was also systems programming language with RC. Going back to my comment "Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.". <devil advocate mode> Give me Swift like Playground, Instruments integration, XCode and LLDB integration. Ability to call any Mac API the same way Swift does. Then maybe our customers will request Rust for our iDevices projects. Give me Visual Studio integration, ability to define WinRT controls like C++/CX, create and debug COM like VC++, mixed mode debugging with .NET. Then maybe our customers will request Rust for our Windows projects. </devil advocate mode> Again, I am pretty aware that Rust is way better than half baked solutions like GSL + static analysis, but I have quite a few grey hairs already. My first C++ compiler was Turbo C++ 1.0 for MS-DOS, remember when it was just released? I also remember when C had zero presence on home computers. Which means I was there when Ada, Modula-2, Modula-3, Oberon and derivatives were steam rolled by OS vendors betting the house in C. As an early C++ adopter, I also carry quite a few flame war scars from being on the C++ side of the fence back on those days (vs C). As I always advocated for the C++ improved safety over what C offers. > And Rust has the most memory-safe low-level systems code available today. I agree, but do the OS vendors that sell the SDKs we are allowed to use, also agree or will hide their head on the sand and do another round of "worse is better" with their tools? > By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time. Yes, but the eco-system is already here. Which means most companies will rather endure a slow Python 2 to Python 3 code re-factoring than move to another language. I really want Rust to succeed and be the language I can use whenever I have to go outside JVM, .NET and mobile worlds. However I have seen too many nice languages become victim of "worse is better" syndrome. So sorry if my type of "heads up comment" isn't welcome.
- weinzierl 11y ago
  Also Rust has the freedom to just leave dangerous features out of the language [1]. This is something we will never be able to do with C++ without transforming it in a not backwards compatible manner. And it's not only about safety: a language that doesn't suffer from the consequences of legacy design choices is just less mental burden, easier to learn and easier to teach. [1] http://graydon2.dreamwidth.org/218040.html http://graydon2.dreamwidth.org/218040.html
  - jguegant 11y ago
    One can simply ditch the C++ backward compatible features into an "unsafe" part of C++. That's exactly what the talk given by Herb at the CppConf is trying to address. All the old unsafe part of C++ will trigger errors or warnings. But if truly necessary one will be able to disable these protections!
    - pcwalton 11y ago
      > All the old unsafe part of C++ will trigger errors or warnings. And by breaking backwards compatibility so heavily, it effectively makes the new safe C++ into a different language.
- jbandela1 11y ago
  I was at the presentations, and basically other than owner<T>, and [[suppress]] I do not remember other annotations. In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations. There were some types to use such as array_view, string_view etc, but not annotations. Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL. He was just contrasting the annotation heavy way Microsoft does static analysis now, with the GSL which does not have these annotations.
  - Manishearth 11y ago
    Check out the actual paper on the isocpp github repo. There are `[[lifetime(foo)]]` annotations. Their proposal does include more elision than Rust (which actually leads to a loss of expressivity of patterns that arise in complex systems), but they still have plenty of annotations.
  - steveklabnik 11y ago
    > Herb made a point that having too many anotations was a weakness of Rust, While he did say that, some other comments of his made it sound like he had checked out older Rust, without elision and with pointer sigils and stuff.
  - pcwalton 11y ago
    I'm referring mainly to [[lifetime(this)]] and friends. Those correspond directly to the lifetime annotations in Rust. Read the paper for more details. > In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations. That's because Herb didn't understand Rust. > Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL. No, I'm referring to the annotations I saw in the paper: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...

pcwalton 11y ago

The lifetime stuff in C++ is full of annotations, with effectively just as many required as Rust. I think of it effectively as a separate language. It's also significantly more complex, with points-to analysis instead of inherited mutability, and the restrictions on pointer aliasing on function entry seem very restrictive compared to what RefCell provides. I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.

pjmlp 11y ago
The danger here to Rust is the usual "worse is better". OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it. Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries. Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes. Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
- pcwalton 11y ago
  > Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. > Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role. And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused. By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.
  - pjmlp 11y ago
    > Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. Have you spent any time reading Apple documentation? https://developer.apple.com/swift/ https://developer.apple.com/swift/ "Swift is a successor to both the C and Objective-C languages." Mesa/Cedar at Xerox PARC was also systems programming language with RC. Going back to my comment "Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.". <devil advocate mode> Give me Swift like Playground, Instruments integration, XCode and LLDB integration. Ability to call any Mac API the same way Swift does. Then maybe our customers will request Rust for our iDevices projects. Give me Visual Studio integration, ability to define WinRT controls like C++/CX, create and debug COM like VC++, mixed mode debugging with .NET. Then maybe our customers will request Rust for our Windows projects. </devil advocate mode> Again, I am pretty aware that Rust is way better than half baked solutions like GSL + static analysis, but I have quite a few grey hairs already. My first C++ compiler was Turbo C++ 1.0 for MS-DOS, remember when it was just released? I also remember when C had zero presence on home computers. Which means I was there when Ada, Modula-2, Modula-3, Oberon and derivatives were steam rolled by OS vendors betting the house in C. As an early C++ adopter, I also carry quite a few flame war scars from being on the C++ side of the fence back on those days (vs C). As I always advocated for the C++ improved safety over what C offers. > And Rust has the most memory-safe low-level systems code available today. I agree, but do the OS vendors that sell the SDKs we are allowed to use, also agree or will hide their head on the sand and do another round of "worse is better" with their tools? > By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time. Yes, but the eco-system is already here. Which means most companies will rather endure a slow Python 2 to Python 3 code re-factoring than move to another language. I really want Rust to succeed and be the language I can use whenever I have to go outside JVM, .NET and mobile worlds. However I have seen too many nice languages become victim of "worse is better" syndrome. So sorry if my type of "heads up comment" isn't welcome.
weinzierl 11y ago
Also Rust has the freedom to just leave dangerous features out of the language [1]. This is something we will never be able to do with C++ without transforming it in a not backwards compatible manner. And it's not only about safety: a language that doesn't suffer from the consequences of legacy design choices is just less mental burden, easier to learn and easier to teach. [1] http://graydon2.dreamwidth.org/218040.html http://graydon2.dreamwidth.org/218040.html
- jguegant 11y ago
  One can simply ditch the C++ backward compatible features into an "unsafe" part of C++. That's exactly what the talk given by Herb at the CppConf is trying to address. All the old unsafe part of C++ will trigger errors or warnings. But if truly necessary one will be able to disable these protections!
  - pcwalton 11y ago
    > All the old unsafe part of C++ will trigger errors or warnings. And by breaking backwards compatibility so heavily, it effectively makes the new safe C++ into a different language.
jbandela1 11y ago
I was at the presentations, and basically other than owner<T>, and [[suppress]] I do not remember other annotations. In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations. There were some types to use such as array_view, string_view etc, but not annotations. Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL. He was just contrasting the annotation heavy way Microsoft does static analysis now, with the GSL which does not have these annotations.
- Manishearth 11y ago
  Check out the actual paper on the isocpp github repo. There are `[[lifetime(foo)]]` annotations. Their proposal does include more elision than Rust (which actually leads to a loss of expressivity of patterns that arise in complex systems), but they still have plenty of annotations.
- steveklabnik 11y ago
  > Herb made a point that having too many anotations was a weakness of Rust, While he did say that, some other comments of his made it sound like he had checked out older Rust, without elision and with pointer sigils and stuff.
- pcwalton 11y ago
  I'm referring mainly to [[lifetime(this)]] and friends. Those correspond directly to the lifetime annotations in Rust. Read the paper for more details. > In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations. That's because Herb didn't understand Rust. > Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL. No, I'm referring to the annotations I saw in the paper: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...