Trailing Block Expressions

[SomeRanDev]

Pass block expressions to macro functions like this:

macro function myMacroFunc(num: Int, e: TrailingExpr): Expr;

// ---

myMacroFunc(123) {
    // block expr
}

Rendered version

[l0go]

Why does it have to be a macro function, couldn't it be expanded for any lambda function?

[SomeRanDev]

Could you clarify what you mean? Do you mean a Kotlin-like feature of allowing trailing blocks to be treated as lambdas that are passed as the final argument to a normal function?

[l0go]

Correct

[SomeRanDev]

As a syntax-sugar lover I would certainly not be opposed to it, and I mentioned trailing lambdas in the "Unresolved Questions" section because I want it to be a part of the discussion, but I personally felt including it as a feature in the proposal would hurt the chances of it being accepted. I figure it's safer to shoot for the syntax first, and if accepted, later proposals for how the trailing blocks can be interpreted for normal functions can be submitted/discussed. And even if those aren't accepted, this proposal still opens the ability to replicate such capabilities using @:build macros.

The reasons I feel trailing lambdas would be shot down are:

• There's no syntax for setting the argument names that is both concise and Haxe-appropriate enough to be accepted.
• There's a "hidden cost" vibe. It feels like you're using a block expression, but you're writing a lambda, which can have drastically different performance implications depending on the platform.

[Pign]

I think this makes it difficult to read in most cases and even creates ambiguous reading.

In your example, the "simple" way of reading the last line (without reading the first one) would be that myMacroFunc has a signature comparable to Int->(TrailingExpr->Void)->Expr. Which is exactly what your first line means but wouldn't it be possible for MyMacroFunc to have the following signature : Int->(TrailingExpr->Expr) ?
This makes it difficult to read and understand the code because of ambiguity.