use blocks

[elyalon]

I remember watching this Brian Will video which had this interesting idea called "use blocks": https://youtu.be/QM1iUe6IofM?si=8RvRO7tr1Hzu45Li&t=2470.

It's essentially just an anonymous function that gets immediately invoked, and even though you can do that in Odin, the syntax for it is both verbose and fault-tolerant.

It gives you the benefit of functions whereas you know that everything that gets executed inside of the use block is entirely dependent on the variables it captures, reducing mental overhead and improving readability. It differs from functions in that it can't be used for abstraction / code-reusability purposes.

What it would look like:

a: int = 5
b: int = 3

res := use(a, b) {
	result := a + b*b
	fmt.printf("result = %d\n", res)
	return result
}

Trying to emulate it with anonymous procs:

a: int = 5
b: int = 3

res := proc(a: int, b: int) -> int {
	result := a + b*b
	fmt.printf("result = %d\n", res)
	return result
}(a, b)

---

Notes:

• In the emulation, you have to specify a and b both for the parameters and the arguments (you would probably always want to keep the parameters' names the same as the variable names you're passing into it).
  • You also have to specify the types.
• The use block would be easily refactorable to a proc.
• It would maybe be better to use a different keyword than return for returning from use blocks, otherwise it might make it harder to find all of the places your enclosing proc can return from.
• Maybe allow an assignment in the use captures, e.g. use(entityp = &entity) {...}.
• The captured variables of a use block should be immutable (just like proc parameters).

Thoughts?

[Feoramund]

There may be a problem with the design of a procedure if it needs to quarantine its own variables in a separate inner scope like this, as opposed to creating a scope for temporary variables that are then discarded after some calculation (which is a pattern that does have use). Variables once declared in a procedure should be necessary for that procedure; it doesn't make sense to isolate them. At that point, it may be necessary to have another procedure.

I can't see any benefit for the complexity this would introduce in both the syntax and the compiler.

[Kelimion]

The proposal reads like an unnecessary detour that ultimately ends up as a nested or top-level procedure, and doesn't seem in any way more convenient than writing it as a nested procedure from the start.

To the contrary, it would introduce another way to do the same thing.

foo :: bar() {
    a := 4
    b := 5

    bar :: proc(a, b: int) -> int {
        return a + b*b
    }
    res := bar(a,b)
}

[elyalon]

I disagree that it's an "unnecessary detour", (I believe) it will make your functions easier to read and reason about, letting you distribute the logic of your long functions to discrete chunks.

I think adding language features just for the sake of "making useful stuff easier" is a good idea, regardless of whether or not it's "already possible".

The complexity cost problem is justified, and I get how this feature is likely not aligned with Odin's design goals.

[Kelimion]

(I believe) it will make your functions easier to read and reason about, letting you distribute the logic of your long functions to discrete chunks.

We already have that by way of nested procedures, and your intent is for successful such use excursions to end up as procedures, which are already "Super easy to read and reason about, letting you distribute your logic into discrete chunks."

In fact the current method is easier to read and reason about than the proposal because they're the same syntax and semantics you're used to. That's why I'm saying it's an unnecessary detour.

In what way is this proposed feature any more convenient than this?

    bar :: proc(a, b: int) -> int {
        return a + b*b
    }
    res := bar(a,b)

[elyalon]

I guess it's true that nested procedures are made for this exact purpose, so it doesn't make sense to add it now.

In what way is this feature any more convenient than?

    bar :: proc(a, b: int) -> int {
        return a + b*b
    }
    res := bar(a,b)

Less syntax and clearer intentions.

[Feoramund]

Get rid of the procedure entirely.

a, b := 32, 64
res: int
{
	a_, b_ := a, b
	res = a_ + b_
}

[Kelimion]

That's exactly one of the reasons we added them: refactor part of a procedure's code into a self-contained scope with full type checking. Then depending on whether it's more widely useful you can yank it out into the package at top-level scope. If not you keep it in the procedure as a nested proc so its business logic is easier to read with the condensed sub-logic.