[SUGGESTION] Compiletime / runtime separation or constexpr, consteval, template<> sickness.

[fro0m]

Just to share my idea of constexpr.
C++ has a strict separation between runtime and compiletime. All about compiletime was assisted with <> characters syntax before constexpr.
And I have no idea why constexpr was introduced. It was easier to embrace <expression> with <> to specify that it is strict compile time.
<i>: int defines compile time variable,
i.e. translates to constexpr int i

if <args.cout> == 3 {
        p = a&;
    }

Forces <expression> to be compile-time, i.e. translates to

if constexpr (args.cout == 3) {
       p = a&;
   }

[AbhinavK00]

I don't think we need to mark all compile time things with <>,the <> was probably chosen with generics in mind, it just happened that all generic related work was done at compile time due to zero overhead principle

[jcanizales]

I'm a fan of the unified const {...} proposal of #255

[JohelEGP]

And I have no idea why constexpr was introduced. It was easier to embrace <expression> with <> to specify that it is strict compile time.

There's no constexpr expression operator.
constexpr is a keyword used in the declarations of entities (and constexpr if).

The way to require that an expression 𝘌 is evaluated at compile-time
is with Cpp1 consteval, e.g., []() consteval -> decltype(auto) { return 𝘌; }().
Although Cpp2 doesn't have an alternative, === might be a candidate (b589f5d#commitcomment-128465809).
Or you can use Cpp1 consteval decltype(auto) constcall(auto&& f) { return CPP2_FORWARD(f)(); }
in Cpp2 with constcall(:() -> forward _ = 𝘌).

[msadeqhe]

Although Cpp2 doesn't have an alternative, === might be a candidate (b589f5d#commitcomment-128465809).

=== reminds me of weakly-typed languages such as JavaScript and PHP.

[msadeqhe]

How about if Cpp2 uses const keyword to mean consteval in function declarations?

// It's a `consteval` function.
fnc1: () const -> i32 = { /*statements...*/ }

Because functions don't have const qualifier in Cpp2 and only functions can be consteval in Cpp1.

[msadeqhe]

Why don't we use Cpp1 keywords?

fnc1: () constexpr -> i32 = 10;

fnc2: () consteval -> i32 = 10;

[msadeqhe]

Perhaps we could also use const to mean consteval because functions don't have const qualifier and only functions can be consteval. For example:

// It's a consteval function.
fnc2: () const -> i32 = 10;

[msadeqhe]

In another words, const in function declarations would mean consteval, but const in variable declarations would mean const as it is. For example:

// It's a `const` variable.
var1: i32 const = 10;

// It's a `consteval` function.
fnc1: () const -> i32 = { /*statements...*/ }

[msadeqhe]

And we can also define functions with const return type:

fnc1: () const -> i32 const = { /*statements...*/ }

The first const means consteval and the second const means const return type.

[AbhinavK00]

I don't think there's const return types required in any cases. Your other suggestion is similar to what I was thinking for consteval functions.

Here's an example from wiki

consteval { // run this block of code at compile time
    if WIN32 != "" || WinVersion > 0 {
        -> { use this code }
    } else {
        -> { use that code }
    }
}

So, I think consteval functions can be simply written as:

func : () -> return_type = consteval {
 //your code
}

[SebastianTroy]

I agree, why complicate and change the meaning of const when we already have keywords in cpp1 On 4 November 2023 15:12:12 Abhinav00 ***@***.***> wrote: I don't think there's const return types required in any cases. Your other suggestion is similar to what I was thinking for consteval functions. Here's an example from wiki consteval { // run this block of code at compile time if WIN32 != "" || WinVersion > 0 { -> { use this code } } else { -> { use that code } } } So, I think consteval functions can be simply written as: func : () -> return_type = consteval { //your code } — Reply to this email directly, view it on GitHub<#644 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQKGGSLZIQOU2LTWDZTYCZLMTAVCNFSM6AAAAAA65QCWB6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TINZUG4YDS>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[realgdman]

I strongly disagree. <> syntax is one thing that bites hard in cpp1. Take for example such simple and common task as converting runtime time code to complie time or back. It will require lot of shuffling and intervening with symblols, instead of just slapping keyword. Compare for example with Zig lang where you write runtime, comptime and build system in one language instead of 3.

[DyXel]

Totally agree with you, and I think this is the direction of contemporary C++ so far; if constexpr, consteval, relaxing constexpr, making more of the STL be constexpr, allowing allocations at compile-time, etc. Ideally you should be able to write compile-time code very similarly to regular code, as opposed to having to resort to things like SFINAE and other advanced template techniques.

[DyXel]

I do want to note however, that I am not a big fan of the ceremony you have with constexpr and consteval in current Cpp1, and I think so far Cpp2 is doing well in terms of avoiding having to type those keywords in the majority of cases.

[AbhinavK00]

One disadvantage I can think of zig style non <> compile time arguments that it can't deduce the types, you always have to provide them.