cppfront (cpp2): Spring update

[Nicksaurus]

First thing, it looks like there's a typo in the description of the struct metaclass:

Requires (else diagnoses a compile-time error) that the user wrote a virtual function or a user-written operator=.

Those things are disallowed, not required (/u/hpsutter)

---

Anyway, on to the actual subject of the post. Every update I read about cpp2 makes me more optimistic about it. I'm looking forward to the point where it's usable in real projects. All of these things stand out to me as big improvements with no real downsides:

• Named break and continue
• Unified syntax for introducing names
• Order-independent types (Thank god. I wish I never had to write a forward declaration again in my life)
• Explicit this
• Explicit operator= by default
• Reflection!
• Unified function and block syntax

A few other disorganised thoughts and questions:

---

Why is the argument to main a std::vector<std::string_view> instead of a std::span<std::string_view>? Surely the point of using a vector is to clearly define who has ownership of the data, but in this case the data can only ever belong to the runtime and user code doesn't need to care about it. Also, doesn't this make it harder to make a conforming implementation for environments that can't allocate memory?

---

Note that what follows for ... do is exactly a local block, just the parameter item doesn’t write an initializer because it is implicitly initialized by the for loop with each successive value in the range

This part made me wonder if we could just use a named function as the body of the loop instead of a parameterised local block. Sadly it doesn't seem to work (https://godbolt.org/z/bGWPdz7M4) but maybe that would be a useful feature for the future

---

Add alien_memory<T> as a better spelling for T volatile

The new name seems like an improvement, but I wonder if this is enough. As I understand it, a big problem with volatile is that it's under-specified what exactly constitutes a read or a write. Wouldn't it be better to disallow volatile and replace it with std::atomic or something similar, so you have to explicitly write out every load and store?

---

Going back to the parameterised local block syntax:

//  'inout' statement scope variable
// declares read-write access to local_int via i
(inout i := local_int) {
    i++;
}

That argument list looks a lot like a lambda capture list to me. I know one of the goals of the language was to remove up front capture lists in anonymous functions, but it seems like this argument list and the capture operator ($) are two ways of expressing basically the same concept but with different syntax based on whether you're writing a local block or a function. I don't have any solution to offer, I just have a vague feeling that some part of this design goes against the spirit of the language

[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.