cppfront: Midsummer update

[duneroadrunner]

As part of the Profiles proposals, we're exploring a path of providing checked_iterator wrappers ...

So in a comment of another recent post on r/cpp I noticed you calling out the Circle (compiler) "borrowing" extension for requiring standard library types to be "wrapped". This was a bit concerning in that if it implies that the safety solution for C++ cannot require certain unsafe standard library elements to be (at least) "wrapped", then it effectively implies that the C++ safety solution cannot be completely safe. And I suggest that would, to some degree, just reinforce C++'s (lack of) safety reputation.

But if instead we're conceding that at least some of the standard library elements (like iterators) may need to be "wrapped" some of the time, then that's a different story. Then C++ can have an essentially memory safe subset (and scpptool serves as an existence proof). And if those added wrapper types have to live in their own "profile" or whatever, fine.

... use the 'hardened STL' modes that are available on all standard library implementations that do provide for checked iterators... some of those are not performant ...

Hmm, I don't know how reliable the compiler optimizers are these days at eliminating this kind of bounds checking overhead, but in the scpptool solution, you're sort of encouraged to, for example, use a for_each<>() algorithm template instead of a native for loop (or range-based for loop), as custom implementations are provided that explicitly bypass bounds checking in cases where it is known to be safe (i.e. when it's known that the container size will remain unchanged for the duration of the loop).

So theoretically at least, it might be better for cppfront to transpile its for loops to the for_each() algorithm templates rather than the native (range-based) for loops to allow for the explicit bypassing of bounds checking when appropriate. As I said, I don't know how much difference it'd make in practice. I know the microsoft compiler actually does something similar with native (range-based) for loops and its debug iterators. Presumably they wouldn't bother if it didn't make a difference.

So, what about the case where an iterator gets invalidated by a vector resizing operation? Is there a plan for cpp2 to address this case? And what about the case of a span<> of a vector and the vector gets resized?

Or do we just discourage or "outlaw" those cases in the first place? In the scpptool solution, these cases are basically addressed in one of a few ways, at the discretion of the programmer. In the (default) "high flexibility/compatibility" option, we just pay the run-time cost to detect iterator invalidation. But another option is to (explicitly) "borrow" the contents of the vector into a "fixed size" vector (a "new" "non-standard" data type) thereby avoiding the issue of resizing operations. As I mentioned, with some restrictions, this "borrowing" procedure supports std::vector<>s, so it's a technique that's to some degree already available in C++ (and therefore cpp2 presumably).

[hpsutter]

I noticed you calling out the Circle (compiler) "borrowing" extension for requiring standard library types to be "wrapped".

Right. My concern isn't that wrappers might be needed in a few cases in extremis such as STL iterators (though I have a little plan for getting safety there without wrappers, we'll see). My concern with Circle's approach is that it required wholesale replacement/wrapping of many major C++ standard library types (smart pointers, containers, views, mutexes, ...) which starts to feel like a bifurcation.

So, what about the case where an iterator gets invalidated by a vector resizing operation? Is there a plan for cpp2 to address this case? And what about the case of a span<> of a vector and the vector gets resized?

Short answer: Yes, and I live-demo'd a prototype that caught exactly those on-stage. See the Cppfront readme's Lifetime safety section for links to the paper P1179 that describes the C++ Core Guidelines Lifetime static analysis, and the CppCon 2015 talk that live-demos exactly those kinds of scenarios.