I'm less familiar with some of the points you made about consistency with aliasing and how it relates to parsing, but I definitely empathize with the point about writing constexpr everywhere. It's a problem without a good solution, in my opinion. There's no place where having constexpr be the default makes more sense than not, and it seems very difficult to infer or make sense of that inference, so we're a bit stuck with having to denote somewhere in the function signature that it's constexpr...

Actually, maybe it is possible to infer constexpr?

A function is not constexpr if:

• It contains references to globals
• It defines variables with static storage durations
• It is a coroutine
• Uses gotos
• If any inputs or outputs are not literal types (i.e. constexpr constructable)

It doesn't seem impossible to deterministically say whether a function is constexpr based on those rules.

All the things that would make a function an invalid constexpr function are also things that make it an impure function too. Maybe if your function isn't pure, you have to mark it with !pure. I haven't thought thru all the consequences of a thing like that, but basic idea being that I think it might actually be possible, with our principles of making information flow well defined, to determine which functions or variables being called are constexpr or not, and then maybe enforce defining them as such or simply inferring it and allowing tooling to notify you of the compilers interpretation.

I don't think that determining constexpr-ness in Cpp2 code has ever been the problem, I imagine it would be a lot of work but I wouldn't say impossible... The real problem is that Cpp2 must transparently work with Cpp1-defined code, and there is no way we'd figure out if something defined in Cpp1 is or isn't constexpr/consteval before lowering to Cpp1 itself (that would defeat the purpose of transpiling, I imagine?). Cppfront could maybe guarantee constexpr in cases where all the definitions used within a function are in Cpp2 code, but then this would silently break as soon as you introduce a Cpp1 construct (including STL stuff), that would be no bueno.

On the other hand, consteval I just don't fully understand why it's needed, they say it will be good for reflection, but I have feeling that cpp2 will have better tools for reflection.

Reflection just can't be done without pure compile time functions, it's not about having a better tool in cpp2. Pure compile time functions will be needed one way or the other, either for reflection or for replacing preprocessor stuff. On the other hand, constexpr is something that isn't really needed, every function can be constexpr by default and if that isn't possible, it could just "decay" to a simple runtime function, lambdas behave this way I think. But there isn't a way I know to do this at transpiler level so constexpr cannot be get rid of.

C++20 consteval is Cpp2 metafunctions: Cpp1 consteval came from this Cpp2 work, years before I announced Cpp2.

Some history: While Andrew Sutton and his team were implementing the Cpp2-based reflection prototype for my P0707 metaclasses paper, Andrew found that he needed a way to guarantee that a function would only run at compile time, because reflection information is only available at compile time. Using constexpr would not be sufficient, because a constexpr function could potentially execute at run time and so it could not validly access reflection information. Since Cpp1 did not have such a "function that can run only at compile time" concept, Andrew proposed (and WG21 accepted) consteval functions to fill that gap.

So Cpp1 added consteval to express Cpp2 metafunctions in a language that didn't yet have reflection and metafunctions of its own. In Cpp2, all reflections are currently used by metafunctions which are compile-time by definition, so the problem doesn't arise.

I've mentioned that <=> was the first Cpp2-derived feature to be approved for ISO C++, and it was... <=> was adopted for C++20 at the November 2017 meeting.

But consteval was too... consteval was adopted for C++20 at the November 2018 meeting. Though, as I mentioned in the previous comment above, consteval wasn't so much directly a Cpp2 feature as it was a workaround to fill a gap in Cpp1 for Cpp1's lack of a Cpp2 feature.

Responding to your point about #⁠1, I see what you say about = being used in a bit of a different way for function definitions, but I don't think it's actually that far from the common use of = or how it's normally conceptualized. In more dynamically typed languages (I'm thinking Javascript and Lua), one way you'd define classes is by assigning a constructor function to a variable:

// From https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
const Rectangle = class Rectangle2 {
 constructor(height, width) {
 this.height = height;
 this.width = width;
 }
};

Or sometimes when defining member functions of an object, you assign the object (dictionary) a field equal to a function:

-- From https://www.lua.org/pil/16.html
Account = {
 balance = 0,
 withdraw = function (self, v)
 self.balance = self.balance - v
 end
}

I think this makes sense because = has a much broader definition in people's minds than == does. = just generally means "assignment", and the use cases and mechanisms by which that happens are different in different languages. In Java, it means setting the value of a primitive or object reference (basically a pointer), and no other logic occurs. In C++ or other systems languages, it can mean construction of a small value or large data type, it can mean moving/copying with an accompanying function call, etc..

Compare that to basically every language where == is valid, in which you expect it to be an operator which takes two arguments, compares them by calling an .Equals() function or similar (or compares outright if they're basic types), and returns a boolean. Much narrower definition. That's not to say that we can't generalize it to fit our needs, but the broadest generalization of its understanding is "comparison" or "equality check/assertion", neither of which remotely come close to describing a type-modifying assignment operator like in cpp2.

This would technically be an improvement on the current situation, but I think unfortunately the majority of issues I identified with == would still exist if we switched to '