reducing complexity in tune

[simonpcouch]

Much of tune's core internals were written >4yrs ago, before the introduction/maturation of more principled tooling for checking, logging, and erroring from cli and rlang, and before the tidymodels packages that tune extends (parsnip, workflows, recipes) themselves had been developed or matured. Paring away some of tune's internal tooling in favor of that from its dependencies—and some of the complexity that grew organically from tune maturing alongside the tidymodels packages—may make the package more maintainable.

Some areas where I see opportunities:

Logging

• Custom dark/light theme handling: https://github.com/tidymodels/tune/issues/737
• Internal tooling for stateless logging: https://github.com/tidymodels/tune/issues/739
• Transitioning to rlang's standalone type checkers: https://github.com/tidymodels/tune/issues/738

  Grid code paths

tune_grid_loop_iter() is the layer of the grid code path that, for a given resample, carries out the preprocessor and model fitting.

• tune_grid_loop_iter() is nested more deeply than it needs to be in the call stack: https://github.com/tidymodels/tune/issues/740
• tune_grid_loop_iter() should name things consistently: https://github.com/tidymodels/tune/issues/741

[jrosell]

Related to https://github.com/tidymodels/tune/pull/794, I think that some kind of richer callback interface could be great. The ones from luz from torch I think they are good examples.

[simonpcouch]

We should be able to make much more headway on the listed issues once we don't have to maintain for some foreach edge cases. While we can start in on some of these now, many will have to wait until the deprecation cycle in #866 is wrapped up, 2 or 3 years out.