Flag argument in layer_*() function

[dajmcdon]

• 👍 Argument is helpful for programmatically accessing layers.
• 👎 Argument is badly named.
• 👎 This functionality is not available in recipes::step_*() functions.

Better may be to operate through the pending update() method for postprocessing.

Other options?

[brookslogan]

Offhand naming ideas:

• .enable, .enabled, .enable_layer, .layer_enabled
• .disable (with inverse logic), .disabled, etc. --- this might be easier to document/explain than "enable", especially if we imagine it'd be significantly more often disabled by update() but not created in a disabled state
• .toggle ("on"/"off" rather than TRUE/FALSE)
• .do_run, .do_enable
• something involving "skip" already taken with a different meaning in steps
• match step_* naming scheme (there is none since if steps don't have this feature, so we're free to choose whatever name)

Not sure about other options as I don't know what all .flag might be used for. Suppose a user calls one of our functions to get some frosting/workflow, then wants to edit / add onto it. Am I on the right track here?:

• User adds their own layer "after layer L". User then tries toggling layer L off by adjusting how they call our workflow-generating function. With .flag, this still runs and does something sensible; with conditional layer creation, it would abort.
• User adds their own layer "after layer L". User then tries toggling a different layer L2 on by adjusting how they call our workflow-generating function. With .flag, they would have already seen L2 and considered it when selecting "after layer L", and they don't have to change it; with conditional layer creation, they either don't need to change anything and it will work (if the correct order is L -> theirs -> L2), or they need to change "after layer L" to "after layer L2" every time they enable layer L2 [and if they didn't notice L2 was a fresh layer or ever forget to change the placement args when enabling L2, they'll get unintended behavior (or an abort if they're lucky)] (if the correct order is L -> L2 -> theirs).
• (Not essential here.) User gets a workflow from one of our functions. They want to try the same thing with some layers disabled. With .flag, they could adjust this with args to the workflow-generator function or with update; with conditional layer creation, they could adjust this with args to the workflow-generator function.
• User gets a workflow from one of our functions. They want to evaluate a few variants of this workflow. With .flag, they can create a reference workflow, and disable layers to get variant workflows; with conditional layer creation, they have to do the same thing but with arg lists, and then use do.call or inject or things along these lines to call our workflow generator function.
• [User gets a workflow from one of our functions. We update that function to add/edit/remove some features. User updates epipredict. User tries to re-run their script. This is probably one of the cases where differences of .flag with other options arises.]

[brookslogan]

I imagine for the above step-insertion cases that use of an "insert new layer between L1 and L2" operation would be less accident-prone than an "insert layer after L1" operation. [And .flag would be valuable in keeping users from having to reword this all the time when they switch to or try multiple variants.]