Thomas Neumann

The grammar already allows for ```move``` annotations in calls (e.g., ```g(move pair.x)```), perhaps we also have to support ```forward``` annotations as in ```g(forward pair.x)```?

Ah, that does not work then. These call annotations are soft keywords of the call site (```expression_list``` in the parser), not part of the expression hierarchy. Then you have to...

Officially they are keywords, we should not treat them as regular identifiers. Otherwise you can define a function called "int". And they behave a bit strange anyway, for example "unsigned...

> I would vote for that. The same rule for all types. No special cases. So either `unsigned long int` is a type and therefore `unsigned long UserType` is too....

From a parsing perspective it is not a problem, it is just that the rules for fundamental types are a bit funny. For example ```signed short int```, ```short int```, ```short...

> Normalizing this is not a problem for `cppfront` since Herb wants the Cpp1 source to resemble what the user wrote for Cpp2. but I think in the long run...

You are right that the bad things will effectively happen in cpp mode, as cpp2 bans pointer arithmetic. But from a safety perspective it is nevertheless bad to teach everybody...

I just realized that my example will fail (as in: compile and crash) even if the signature of `myprint` would be `(c: string_view)`... The implicit conversion of `const char*` to...

Consider this code snippet here: ``` f1 : () = { x: Foo; f2(out x); } f2: (out x : Foo) = { f3(out x); } f3: (out x :...

> Why must it be destroyed when leaving f3? Oh, because it was constructed in a lower function. Maybe instead of recording "I constructed it", `out` should be recording "it...