seanbax

Which ideas aren't strictly necessary to achieve safety in C++?

That's the definition of std::sort. What aliasing information can be gleaned from local analysis of the function? Absolutely nothing.

  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());
    }

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.

I illustrate why it won't work with a number of examples here: https://www.circle-lang.org/draft-profiles.html

To address your points: 1. The safe subset of C++ is too small to do anything with. 2. The Standard Library is not written in the safe subset.

My favorite example from the above paper is the problem of std::sort -- the compiler has no idea if both operands are iterators into the same allocation. The function is fundamentally unsafe. Which C++ profile do you turn on to make that safe? Does it ban use of std::sort? Does it ban use of all <algorithms>, all of which work on pointers/iterators that are susceptible to use-after-free UB?

The whole Standard Library is unsafe. I proposed a rigorously safe std2, and that was rejected. And now you propose a safe std2 (using refcounting primitives)--why would that fare better? What does Profiles actually propose? No change in existing code. The compiler simply finds all UB. Right.

The Profiles authors are the ones claiming this uses local analysis only: https://news.ycombinator.com/item?id=41942126

They are clear that Profiles infers everything from function types and not function bodies. Obviously that won't work, but that's what they say.

I would have implemented profiles if profiles had a chance of working. But they will not ever work. I present many examples of why they fail here: https://www.circle-lang.org/draft-profiles.html

People who say Profiles are a path forward, please address any of the points in this document.

You do solely rely on the declaration.

From P3465: "why this is a scalable compile-time solution, because it requires only function-local analysis"

Profiles uses local analysis, as does borrow checking. Whole program analysis is something you don't want to mess with.

If the vector has to be resized in push_back, the implementation copy-constructs a new object from x. It resizes the buffer. Then it move-constructs the copy into the buffer. The cost is only a move construct per resize... So it's on the order of log2(capacity). Very efficient. But don't get used to it, because there are plenty of other C++ libraries that will break under aliasing.

From P3465: "why this is a scalable compile-time solution, because it requires only function-local analysis"

From P1179: "This paper ... shows how to efficiently diagnose many common cases of dangling (use-after-free) in C++ code, using only local analysis to report them as deterministic readable errors at compile time."

Local analysis only. It's not looking in function definitions.

Whole program analysis is extremely complicated and costly to compute. It's not comparable to return type deduction or something like that.

Presenting a familiar syntax certainly makes it easier to follow.

https://itanium-cxx-abi.github.io/cxx-abi/abi.html See all the stuff there? exceptions, vtable layout, rtti, mangling, etc. There's a Windows equivalent for all of that. That's what I want access to.

Yes, interfaces open that up, and to a lesser extent choice types open that up. If your choice type supports all the alternatives from the original overload set, then you can reduce to one function.

That's right. I'm fine with normal C++ syntax. But other people have other opinions. And there is an allure of getting to a CFG so that non-compiler tooling could build a parse tree and do useful transformations. That's a good a goal.

I'm basically looking to evolve on multiple fronts at once. If there's an interest in new syntax, put resources. If there's interest in a borrow checker (I'm sure there is), put resources there. Just move up the field however you can.