[Feature Request] Parsimonious re-use of branches?

[emstruong]

Hello again,

Related to #132 , I was wondering if parsimonious selective re-use of branch options could be allowed?

For example, in the following reprex, the different branch options need to be repeated even though nothing is done.

library(multiverse)
#> Loading required package: knitr

M <- multiverse::multiverse()

# Parsimony of expression
multiverse::inside(M, {
  x<-branch(options,
            "a" ~ 1,
            "b" ~ 2,
            "c" ~ 3)
})

multiverse::inside(M, {
  branch(options,
             "a" ~ {y <- 1},
             "b" ~ {NA},
             "c" ~ {NA})
})
# THIS IS OK

multiverse::inside(M, {
  branch(options,
         "a" ~ {z <- 1})
})
#> Error in get_parameter_conditions_list(unname(.code)): reused parameters should have the same number of options and the same names for each option as the original declaration

^{Created on 2025-10-06 with reprex v2.1.1}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.5.1 (2025-06-13)
#>  os       Ubuntu 22.04.5 LTS
#>  system   x86_64, linux-gnu
#>  ui       X11
#>  language en_CA:en
#>  collate  en_CA.UTF-8
#>  ctype    en_CA.UTF-8
#>  tz       America/Toronto
#>  date     2025-10-06
#>  pandoc   3.6.3 @ /usr/lib/rstudio/resources/app/bin/quarto/bin/tools/x86_64/ (via rmarkdown)
#>  quarto   1.6.33 @ /usr/local/bin/quarto
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  ! package        * version date (UTC) lib source
#>    abind            1.4-8   2024-09-12 [1] RSPM
#>    berryFunctions   1.22.13 2025-07-28 [1] RSPM
#>    cli              3.6.5   2025-04-23 [1] RSPM
#>  P codetools        0.2-20  2024-03-31 [3] CRAN (R 4.5.1)
#>    collections      0.3.9   2025-08-18 [1] RSPM
#>    digest           0.6.37  2024-08-19 [1] RSPM
#>    distributional   0.5.0   2024-09-17 [1] RSPM
#>    dplyr            1.1.4   2023-11-17 [1] RSPM
#>    evaluate         1.0.5   2025-08-27 [1] RSPM
#>    fastmap          1.2.0   2024-05-15 [1] RSPM
#>    formatR          1.14    2023-01-17 [1] RSPM
#>    fs               1.6.6   2025-04-12 [1] RSPM
#>    furrr            0.3.1   2022-08-15 [1] RSPM
#>    future           1.67.0  2025-07-29 [1] RSPM
#>    generics         0.1.4   2025-05-09 [1] RSPM
#>    globals          0.18.0  2025-05-08 [1] RSPM
#>    glue             1.8.0   2024-09-30 [1] RSPM
#>    hms              1.1.3   2023-03-21 [1] RSPM
#>    htmltools        0.5.8.1 2024-04-04 [1] RSPM
#>    jsonlite         2.0.0   2025-03-27 [1] RSPM
#>    knitr          * 1.50    2025-03-16 [1] RSPM
#>    lifecycle        1.0.4   2023-11-07 [1] RSPM
#>    listenv          0.9.1   2024-01-29 [1] RSPM
#>    magrittr         2.0.4   2025-09-12 [1] RSPM
#>    multiverse     * 0.6.2   2024-10-07 [1] RSPM
#>    parallelly       1.45.1  2025-07-24 [1] RSPM
#>    pillar           1.11.0  2025-07-04 [1] RSPM
#>    pkgconfig        2.0.3   2019-09-22 [1] RSPM
#>    purrr            1.1.0   2025-07-10 [1] RSPM
#>    R.cache          0.17.0  2025-05-02 [1] RSPM
#>    R.methodsS3      1.8.2   2022-06-13 [1] RSPM
#>    R.oo             1.27.1  2025-05-02 [1] RSPM
#>    R.utils          2.13.0  2025-02-24 [1] RSPM
#>    R6               2.6.1   2025-02-15 [1] RSPM
#>    readr            2.1.5   2024-01-10 [1] RSPM
#>    reprex           2.1.1   2024-07-06 [1] RSPM
#>    rlang            1.1.6   2025-04-11 [1] RSPM
#>    rmarkdown        2.29    2024-11-04 [1] RSPM
#>    rstudioapi       0.17.1  2024-10-22 [1] RSPM
#>    sessioninfo      1.2.3   2025-02-05 [1] RSPM
#>    styler           1.10.3  2024-04-07 [1] RSPM
#>    tibble           3.3.0   2025-06-08 [1] RSPM
#>    tidyr            1.3.1   2024-01-24 [1] RSPM
#>    tidyselect       1.2.1   2024-03-11 [1] RSPM
#>    tzdb             0.5.0   2025-03-15 [1] RSPM
#>    vctrs            0.6.5   2023-12-01 [1] RSPM
#>    withr            3.0.2   2024-10-28 [1] RSPM
#>    xfun             0.53    2025-08-19 [1] RSPM
#>    yaml             2.3.10  2024-07-26 [1] RSPM
#> 
#>  [1] /home/mstruong/.cache/R/renv/library/DT-MV-Dev-18a30900/linux-ubuntu-jammy/R-4.5/x86_64-pc-linux-gnu
#>  [2] /home/mstruong/.cache/R/renv/sandbox/linux-ubuntu-jammy/R-4.5/x86_64-pc-linux-gnu/179fe56a
#>  [3] /opt/R/4.5.1/lib/R/library
#> 
#>  * ── Packages attached to the search path.
#>  P ── Loaded and on-disk path mismatch.
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[abhsarma]

The issue I anticipate here is distinguishing between intended use of a subset of options and filling with "NAs" vs detecting actual oversight in someone's code where they missed one or more options.

The only feasible alternative I guess is to throw warnings instead of errors.

[emstruong]

Hi @abhsarma , warnings could work -- but are warnings already stored? I know I can retrieve .errors, but I can't remember off the top of my head whether .warnings exists and can also be retrieved... I suspect no based on my quick googling, but I'm not sure...

[abhsarma]

Warnings are not stored, only errors are :)

However, I am not sure if warnings are a good idea---warnings are often ignored/suppressed and in that case, this type of usage pattern can probably lead to more dangerous mistakes in a statistical analysis. I might have think this over for a bit.

[emstruong]

Oh, well I think it could be very important to be able to store both warnings/errors; and also having a good way of easily tabulating/organizing which errors/warnings happen with what combinations of decisions.

For example, brms can give a lot of warning messages that are scientifically important in guiding how you should interpret the results, but tends not to give flat-out errors.

On a related note, warnings tend to have a 'general' and a 'specific' component to them. So an effective organization scheme of the warnings might benefit from the ability to aggregate warnings that are actually similar to each other.