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: Custom dark/light theming #737
• Internal tooling for stateless logging: Transition from helpers for constructing condition messages #739
• Transitioning to rlang's standalone type checkers: Transitioning from home-grown type checkers #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: nestedness of grid code paths #740
• tune_grid_loop_iter() should name things consistently: clarify naming of intermediate objects in tune_grid_loop_iter() #741

[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.