You pipsqueaks want memory safety? We'll show you memory safety! We'll borrow that borrow checker
  • zygo_histo_morpheus
    13·
    4 hours ago

    I’m a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn’t have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn’t even possible if you’re e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.

    Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.

    • Tobias Hunger
      7·
      3 hours ago

      Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, …), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.

      The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.

      • zygo_histo_morpheus
        1·
        46 minutes ago

        Ah ok just read the article and not the proposal. I’m surprised that they went that far but as I wrote I think that lifetime annotations are a good idea, hope the C++ people find a way to add them to the language that actually works well, which sounds like an incredibly difficult task.

  • Troy@lemmy.ca
    361·
    6 hours ago

    I’ve done a bit of C++ coding in my time. The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore. I don’t know if this is a good thing or not to keep adding and extending or whether C++ should sail into the sunset like Fortran and others before it.

    • ButtonsEnglish
      21·
      6 hours ago

      Fortran is still a good language for some purposes I think.

      And I feel the same way, C++ tries to solve the problem of having too many features by adding more features.

      • Troy@lemmy.ca
        10·
        6 hours ago

        Don’t get me wrong. There is still a time and a place for Fortran. And this will also likely always be the case for C++. But I’m not sure it is entirely wise to choose it if you’re creating a new project anymore.

        • Valmond@lemmy.world
          2·
          1 hour ago

          You might be right, but I have heard that song a lot of times, python, java, ml, pascal, obscure webdev.languages, AI will do it, typescript, etc etc etc

          I’d go with a better python than rust, you can put that “once in a lifetime asm optimized memsafe multi threaded code” in a package and just use it from python. But python has GIL and you can’t just remove it so who knows what will be the next shiny thing? Probably several languages, like for easy peasy stuff up to hardcore multi threaded memory safe stuff. Gotta push us oldtimers out in some way, right :-) ?

          • ladEnglish
            2·
            1 hour ago

            A lot of computational heavy tasks for science were done in Fortran at least ten years ago (and I think still are). I was told that’s mainly because Fortran has a good deal of libraries for just that, and it was widely taught in academia so this is a common ground between the older and newer generations.

            I think it may be gradually superseded by Python, but I don’t know if it is

    • thingsiplay@beehaw.org
      51·
      4 hours ago

      C++ innovates often first and adapts it into mainstream. And its kind of a swiss-army knife. You don’t need to use and learn everything, just pick what you need. Unless you need to get into an old existing code base…

      Just an idea: The language could be divided into multiple standard levels, where each level has more features and functionality. It would be essentially a “restricted”, “standard” and “full” version of the language, where full is basically what it is now and the others are constrained versions with less functionality (no multiple inheritance and what not rules). But at this point, if you don’t use the language in its full, why bother with it at all? Just thinking a bit…

      • ladEnglish
        1·
        1 hour ago

        You don’t need to use and learn everything, just pick what you need.

        I used to think the same, but now I think you should at least skim through everything. Reason being otherwise you may reinvent the wheel a lot, and there are many use-cases where you really don’t want to do that (but C++ makes it so easy, I was constantly tempted to just do what I want and not look for it being already available)

  • litchralee@sh.itjust.worksEnglish
    17·
    5 hours ago

    On one hand, I’m pleased that C++ is answering the call for what I’ll call “safety as default”, since as The Register and everyone else since pointed out, if safety constructs are “bolted on” like an afterthought, then of course it’s not going to have very high adoption. Contrast this to Rust and its “unsafe” keyword that marks all the places where the minimum safety of the language might not hold.

    On the other hand, while this Safe C++ proposal adopts a similar notion of an “unsafe” context, it also adds a “safe” keyword, to specify that a function will conform to compile-time safety checks. But as the proposal readily admits:

    Rust’s functions are safe by default. C++’s are unsafe by default.

    While the proposal will surely continue to evolve before being implemented, I forsee a similar situation as in C where code that lacked initial const-correctness will struggle to work with newer code and libraries. In this case, it would be the “unsafe” keyword that proliferates everywhere just to call older, unsafe code from newer, safe callers.

    Rust has the advantage that there isn’t much/any legacy Rust to upkeep, and that means the volume of unsafe code in Rust proframs is minimal, making them safer overall today. But for Safe C++ code, there’s going to be a lot of unsafe legacy C++ code and that reduces the safety benefit for programs overall, for the time being

    Even as this proposal progresses, the question of whether to start rewriting some code anew in Rust remains relevant. But this is still exciting as a new option to raise the bar in memory safety in C++.