I was curious about the concept of inverting this – requiring that all variables lazily evaluate, and in the case that evaluation is needed now, some keyword obtains it. But when I think about it, that's sort of just `await`.

I'm curious as to if it's feasible to syncretise these two aspects of variable evaluation into a shared feature that makes async and sync code feel alike.

> I was curious about the concept of inverting this – requiring that all variables lazily evaluate, and in the case that evaluation is needed now, some keyword obtains it.

That's how Haskell works. Everything is lazily evaluated, and in the case that evaluation is needed now, the "seq" function obtains it (https://wiki.haskell.org/Seq).

It’s called lazy evaluation but it isn’t really anything like await. Await blocks on a computation that is already running; it doesn’t begin evaluation only when you await it.

In any sane language you can just do this using a lambda. Unfortunately C is just broken so :(

Isn't alias handled by the C pre-processor's #DEFINE operation?

  #DEFINE NOT_NULL(x) (bool)x
  #DEFINE NOT_SPACE(x) ( ' ' != *x )
  // ...
  if ( NOT_NULL(v) && NOT_SPACE(v) ) { ... }

Technically, this is true, but most C++ programmers are very reluctant to use macros except for stuff like include guards or stuff like NDEBUG.

The reason is mainly the many language construct of C++ cover most traditional use cases of macros when programming C while at the same time being much less error prone than macros.

A sibling show how one easily can achieve the very same thing using short lambdas instead. That variant is also bound to the scope one is currently in, and in order to have that safety with a macro one would need to undefine the macros afterwards. One would also need to check that they are not yet defined beforehand, and if so restore the previous macro afterwards in order to not break completely unrelated code in case of macro name clashes.

Yep, #defines are non-lexical and add way too much clutter to be useful in this case, even when you’re non-reluctant in general.

It is not a direct implementation, and may end up being clunky, but I expect a fairly small library of helper functions could improve ergonomics quite a bit:

Define your booleans as functions of no args. A sample in Python:

    var = 'abc'
    var_contains_a = lambda: 'a' in var
    var_shorter_than_5 = lambda: len(var) < 5

    if var_contains_a() and var_shorter_than_5():
        print(var)

One challenge with the chosen example language, Python, is that functions are truthy. So if you forget to call the function that computes your boolean test, you end up with a default true.

Taking the last top-level statement, the `if`:

    if var_contains_a() and var_shorter_than_5: #note the lack of parens for the second
        print(var)

This will print a string of any length that contains 'a' (or any other collection that implements `in` and does, in fact, contain an element, 'a'). The second function is passed directly as a boolean expression, and being a function, it resolves to true.

I do this in c++ quite often with short lambdas

  auto not_null = [&]{ return (bool)p; };
  auto not_space = [&]{ return (*p != ' '); };

  if (not_null() && not_space()) {

It's not quite as ergonomic but it works.

As an aside. I was curious if the compiler will optimize in the short circuit even if you extract the eagerly evaluated named booleans. However I was pretty sure the rules of c++ are against you and tests show this to be the case

But if you simulate the alias keyword with lambdas then the result after optimization are the same

https://godbolt.org/z/3cczcnK4s

>I was curious if the compiler will optimize in the short circuit even if you extract the eagerly

It will optimize, but not necessarily what you wanted... Because null dereference is UB (with default compiler flags), it's allowed to elide null check.

Scala has lazy val