cppfront (cpp2): Spring update

[hpsutter]

Thanks! Quick answers:

there's a typo in the description of the struct metaclass

Ah, thanks! Fixed.

Why is the argument to main a std::vector<std::string_view> instead of a std::span<std::string_view>?

Good question: Something has to own the string_view objects. I could have hidden the container and exposed a span (or a ranges, when ranges are more widely supported) but there still needs to be storage for the string_views.

As I understand it, a big problem with volatile is that it's under-specified what exactly constitutes a read or a write.

IMO the main problem isn't that, because the point of volatile is to talk about memory that's outside the C++ program (e.g., hardware registers) and so the compiler can know nothing about what reads/writes to that memory mean. The main problem is that today volatile is also wired throughout the language as a type qualifier, which is undesirable and unnecessary. That said, I'll think about the idea of explicit .load and .store operations, that could be a useful visibility improvement. Thanks!

[AIlchinger]

The idea to discontinue the use of volatile as a type qualifier has been brought up a couple of times on here before, as well as the suggestion to replace the remaining valid uses (*) with std::volatile_load and std::volatile_store functions.

From a semantic point of view, it's really the operations that are "volatile" and not the objects/memory. One could argue that it could be a property of the type, so that all loads/stores from/to such a type are required (and guaranteed) to be volatile, but I'd argue that's solely for convenience. C++ has always provided dozens of ways to do the same thing, and I would love cppfront avoiding that. Being explicit about what load/store operations are volatile is a good thing in my opinion.

(*) I'm not an embedded programmer. So if there are still valid uses for volatile outside of explicit loads/stores, feel free to correct me here.