Safe C++ Proposal Is Not Being Continued

Well like you said, Fortran didn't actually go anywhere. Fortan 77 is a terrible programming language, but you can't seriously claim it "disappeared from the Earth".

Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do.

There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. That's like man on the moon stuff, genuinely impressive. Mostly though C++ is a garbage fire and so while it's important to learn about it and from it we should not keep doing that.

> I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.

People have tried variants of this already: Carbon, for example. I don’t think anyone outside of Google uses it, though, and even within Google I suspect it’s dwarfed by regular C++.

I don’t think C++ will become irrelevant for a long time. Recent standards have added some cool new features (like std::expected), and personally I feel like the language is better than ever (a biased opinion obviously).

Memory management is still a huge elephant in the room, but I don’t think it’s becoming irrelevant.

> fork both C++ and Clang

Great! What are you waiting for?

If you try to answer that question, you'll also find why other similar projects are not finding much traction yet.

FWIW, Rust doesn't have specialization yet because they're really hard to get right without introducing new undefined behaviors.

This doesn't mean that it's not possible to achieve a safe subset of C++ that supports template specialization, but it suggests that we aren't going to see it any time soon.

I've been thinking for a while now about using dependant typing to enforce good numerics in numerics kernels. Wouldn't it be nice if we could propagate value bounds and make catastrophic cancellation a type error?

Have you worked much with SAL and MIDL from Microsoft? Using SAL (an aesthetically hideous but conceptually beautiful macro based gradual typing system for C and C++) overlay guarantees about not only reference safety but also sign comparison restriction, maximum buffer sizes, and so on.

    typedef unsigned int __attribute__ ((constraint (X != 5 && X != 42))) my_type;

To be even more precise:

> Reference counting is the primary mechanism of garbage collection, however, it doesn’t work when the references have cycles between them and for handling such cases it employs the GC.

Python doesn't have lvalues in the way that C++ and Rust do. You can't refcount everything and still pass lvalues to subobjects. If lvalues to subobjects are important, you need borrow checking.

> Jython, IronPython

Both of which have modern, concurrent, parallel, and generational garbage collectors.

Geoff's stuff is mostly about heuristics. For his purpose that makes sense. If Apple are spending say $1Bn on security problems and Geoff spends $1M cutting such problems by 90% that's money well spent. The current direction of profiles is big on heuristics. Easy quick wins to maybe get C++ under the "Radioactively unsafe" radar even if it can't pass for safe.

The most hopeful thing I saw in Geoff's talk was cultural. It sounds like Geoff's team wanted to get to safer code. Things went faster than expected, people landed "me too" unsolicited patches, that sort of thing. Of course this is self-reported, but assuming Geoff wasn't showing us a very flattering portrait of a grim reality, which I can't see any incentive for, this team sounds like while they'd get value from Rust they're delivering many of the same security benefits in C++ anyway.

Bureaucrats don't like culture because it's hard to measure. "Make sure you hire programmers with a good culture" is hard to chart. You're probably going to end up running some awful quiz your team hates "Answer D, A, B, B, E, B to get 100%". Whereas "Use Rust not C++" is measurable, team A has 93% of code in Rust, but team B scored 94.5% so that's more Rust, they win.

D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires.

These include:

1. bounds checked arrays (you can still use raw pointers instead if you like)

2. default initialization

3. static checks for escaping pointers

4. optional use of pure functions

5. transitive const and immutable qualifiers

6. ranges based on slices rather than pointer pairs

They could also care about safety but just not like the Rust approach.

“But those people aren't going to join language committees.”

This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential

Like the google people who can't convince them and went on to create carbon?

I don't know that they don't care about safety. They just don't agree with the definition others have picked. I remember when managed code became a thing. I being an old c++ dev noted that memory was always managed. It was managed by me.

> Normally no one talks anymore about things like buffer overflows, use after free,... since years

Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.

> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.

How so? By listing all dependencies in an easy to digest way?

Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it.

"Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done.

Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository).

Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there.

> Currently I see no existential risk at all.

I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed.

When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.

The analysis you link to is insufficient.

E.g., the first case is "Inferring aliasing". He presents some examples and states, "The compiler cannot infer a function’s aliasing requirements from its declaration or even from its definition."

But why not?

The aliasing requirements come directly from vector. If the compiler has those then determining the aliasing requirements of those functions is straightforward.

Now, maybe there is some argument that a C++ compiler cannot determine the aliasing requirements of vector, but if that's the claim, then the paper should make it, and back it up.

The paper continues in the same vein in the next section, as if the lifetime requirements of map and min cannot be known or cannot bubble up through the functions that call them.

As written, the paper says almost nothing about the feasibility of static analysis of C++ to achieve safety goals for C++.

  int* func(int* a);

  template<typename _RandomAccessIterator>
    _GLIBCXX20_CONSTEXPR
    inline void
    sort(_RandomAccessIterator __first, _RandomAccessIterator __last)
    {
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
     _RandomAccessIterator>)
      __glibcxx_function_requires(_LessThanComparableConcept<
     typename iterator_traits<_RandomAccessIterator>::value_type>)
      __glibcxx_requires_valid_range(__first, __last);
      __glibcxx_requires_irreflexive(__first, __last);

      std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
    }

You have to realize that the number of locations in code where reference counter adjustment is actually meaningful is rather small and there are simple rules to keep the excess thrash from reference counting pointer wrappers to a minimum. The main one, as mentioned in the talk the sibling comment called out, is that it is OK to pass a raw pointer or reference to a function while holding on to a reference count for as long as that other function runs (and doesn't leak the pointer through a side effect). This rule catches a lot of pointless counter arithmetic through excessive pointer wrapper copying.

> For bounds checking, sure I think the performance penalty is so small that it can be done.

Depends on how many times it's inlined and/or if it's in hot code. It can result in much worse assembly code.

Funny thing: C++17 string_view::substr has bound check + exception throw, whereas span::subspan has neither; I can see substr's approach being problematic performance- and code-size-wise if called many times yet being validated by caller.

That would have been my first guess but WebKit's experience doing exactly this is the opposite.

See https://www.youtube.com/watch?v=RLw13wLM5Ko

Note that they also allowed other kinds of pointers so long as their use could be statically verified using very simple rules.

> This is not the goal of profiles. It’s to be “good enough.” Guaranteed safety isn’t in the cards.

- Rust isn’t totally guaranteed safe since folks can and do use unsafe code.

- Exact same situation in Swift

- Go has escape hatches like it you race, but not only.

So most “safe” things are really “safe enough” for some definition of “enough”.

I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety. So I don't buy your first and second points.

> Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck.

That's a bold statement. It might be true for some very loose definition of "borrow checker". See the super simple static analysis that WebKit uses (that presentation is now linked in at least two places on this HN discussion, so I won't link it again).

> Your idea to do the reference counting everywhere is not something WG21 has looked at, I think the perf cost is sufficiently bad that they won't even glance at it. They're also not going to ship a GC.

The point isn't to have ref counting on every pointer at the language level, but rather: if your prevent folks from calling `delete` directly (as one of the profiles does) then you're effectively forcing folks to use smart pointers.

Reference counting that happens by smart pointers is something that they would ship. We know this because it's already happened.

I imagine this would really mean that some references are ref counted (if you use shared_ptr or similar) while other references use some other policy.

> Finally though, C++ is a concurrent language. It has a whole memory model which doesn't even make sense if you aren't thinking about concurrency. But to deliver concurrent memory safety without Fil-C's overheads you would want... well, Rust's Send and Sync traits

Yeah, this might be an area where they leave a hole. Like, you might have reference counting that is only partially thread safe:

- The refcount of any object is atomic.

- The smart pointer itself is racy. So, racing on pointers can pop the protections.

If they got that far, then that wouldn't be so bad. The marginal safety advantage of Rust would be very slim at that point.

+1 ... Rust has done pretty much the minimal thing that one needs to write C/C++ like programs safely... things must fit together to cover all scenarios (borrow checker / mut / send / sync / bounds checking). Especially for multithreading.

C++ / profiles will not be able to do much less or much different to achieve the same goals.

Additionally they ignore field experience, I can tell that on VC++ the lifetime checker only has worked in small examples, as I was really into trying it out.

Microsoft even has blog posts admitting that only with SAL like annotations it can be improved, while keeping the usual C++ semantics.

Yet WG21 has ignored this field experience.

this is kinda the opposite of what i think people really want. they want an LLL with borrow checking without all of the abstractions and baggage you get in rust.

Isn't ReasonML pretty much that language already? Although the most popular language in that broader niche is probably Golang.

If unsafe is not used, then no one has to determine whether the unsafe parts are actually safe.

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

I just start everything with

    #![forbid(unsafe_code)]

Sigh. As I point out occasionally, the halting problem very rarely comes up in practice. Combinatorial explosion, yes, but not actual undecidability.

Understanding the implicit constraints of C/C++ functions is something where an LLM can help. Once you have the constraints recorded, they become formal constraints at the call. Historic C isn't expressive enough for even basic constraints.

Most of the constraints mentioned are at least expressible in Rust.

> Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower.

That works fantastically when you're rewriting something - you already have the idea and final product nailed down.

It works poorly when you don't have everything nailed down and might switch a lot of stuff around, or remove stuff that isn't needed, etc.