inorder=FALSE does not work

[elixiasme]

Describe the bug
Using the .inorder=FALSE flag does not stop returning in order, the function still seems to wait to return results in sequential order.

Reproduce example

library(doFuture)

plan(multisession, workers = 10)

results <- foreach(
  i = seq_len(10),
  .combine = function(...) c(...),
  .options.future = list(seed = TRUE),
  .inorder = FALSE
) %dofuture%
  {
    a = runif(1, min = 0, max = 5)valuse
    Sys.sleep(a)
    return(i)
  }
print(results)

[1] 1 2 3 4 5 6 7 8 9 10

when a is returned using return(a) :

[1] 9.004456 8.136491 8.708837 4.002061 8.468867 1.739723 6.838177 7.355555 7.404953 9.821443

Expected behavior
Return values to the .combine function as they come, returning something like:

[1] 6 4 7 8 9 2 5 1 10

Session information

R version 4.5.1 (2025-06-13)
Platform: x86_64-pc-linux-gnu
Running under: Manjaro Linux

Matrix products: default
BLAS: /usr/lib/libblas.so.3.12.0
LAPACK: /usr/lib/liblapack.so.3.12.0 LAPACK version 3.12.0

locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C LC_TIME=de_DE.UTF-8 LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/Berlin
tzcode source: system (glibc)

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] doFuture_1.1.3 future_1.68.0 foreach_1.5.2

loaded via a namespace (and not attached):
[1] compiler_4.5.1 parallelly_1.45.1 parallel_4.5.1 tools_4.5.1 rstudioapi_0.17.1 future.apply_1.20.1
[7] listenv_0.10.0 codetools_0.2-20 iterators_1.0.14 digest_0.6.39 globals_0.18.0

[HenrikBengtsson]

Hello, thanks for this. I'm curious of your use case there? Are you trying to optimize performance or memory use? Or are you looking into what %dofuture% replicate from the %dopar% of, say, doParallel, behaviors?

FWIW, the exact behavior of .inorder = FALSE is not strictly defined, but ?foreach::foreach does mention "performance" being a reason for why it was added in the first place:

.inorder: logical flag indicating whether the .combine function requires the task results to be combined in the same order that they were submitted. If the order is not important, then it setting .inorder to FALSE can give improved performance. The default value is 'TRUE.

I read this that .inorder = FALSE does not have to be implemented - it's up to the foreach adapter - so technially not a bug here.

Now, with the major internal rewrite that was came with future (>= 1.40.0) [2025-04-10], the future::value() method for lists of futures gained skills on reducing results effciently. On can do things like:

ys <- value(fs, reduce = `c`, inorder = FALSE, drop = TRUE)

That will reduce as soon as possible, and drop objects no longer needed as soon as possible. See https://future.futureverse.org/reference/value.html for details. For a discussion behind these features, see futureverse/future#681.

The current implementation of %dofuture% uses ys <- value(fs). I haven't had time to look into the details, I can imagine one could map .combine and .inorder of foreach() to arguments reduce and inorder of value().

[elixiasme]

Yes, the goal was to reduced overhead performance and/or memory wise caused by keeping things inorder as it is not needed in my use case.
I thought it was a setting commonly implemented and not working correctly, in this case I guess it is not a bug.