how to best short-circuit entire template evaluation

[jayunit100]

possible workaround, from conv w dimitry, using a .lib.yaml.... Describe the problem/challenge you have

Right now, we have to sometimes nest 1000s of lines of yaml in a

#@ if
...
#@end

block, which can be hard to reason about (i.e. what is this #@end referring to?)...

https://github.com/vmware-tanzu/tanzu-framework/blob/main/pkg/v1/providers/infrastructure-vsphere/v0.7.10/ytt/overlay.yaml

Describe the solution you'd like

Something like

#@ if not data.values.IS_WINDOWS_WORKLOAD_CLUSTER:
    #@ break;
#@end

so that we can short circuit (or not) the processing of a file in some way.

[pivotaljohn]

In general, the ability to write guard clauses can make it easier to reason over a function (lowercase 'f'). 👍🏻 It's effectively a kind of precondition which alleviates the reader from being concerned about that condition for the rest of the execution.

Turning towards implementation concerns...

More context:

• return is only allowed within a function
• continue and break are only allowed within a loop

Options:

• introduce a new built-in: stop or interrupt
• a function within the @ytt:assert module?!

Concerns:

• how to end execution within a Starlark program in a way that the runtime sees it as a successful execution (which it's been somewhat designed to flow all the way through the program)?

[cppforlife]

return is only allowed within a function

that's still one of the options. we can rewrite ast to support return at top level. question is it a good idea?

[pivotaljohn]

I'm on the fence, ATM.

On the one hand — as I noted above — guard clauses can made a larger script much more easier to reason about.

On the other hand, this mechanism can be used to terminate execution anywhere in the script. Imagine there's a return in the middle of the example Jay gave... ugh.

[cppforlife]

im also on the conservative side for such change, since it may come with its own set of sharp edges.