How many elements are sorted for a worst case?

I feel like sorting always would be better than sorting sometimes, as it reduces opportunities for inconsistency. Given that I assume you've changed all instances of GetPathNames, this seems safe enough based on what they do.

If not, I would recommend passing an enum VFS::SORTED or something instead of true or false since C++ doesn't have named arguments.

Could be a lot for people who save their games quite often.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/989/

I think the time taken sorting some files by C++ code is irrelevant.

In D1756#71172, @wraitii wrote:

I think the time taken sorting some files by C++ code is irrelevant.

#metoo, but that doesn't make it true.
How many JS files do we load, < 100? That should be done within microseconds or something. The one place where > 100 could be loaded is the ColladaManager.cpp and that already does sort. *.po files are very few too, if they were sorted.

To prove the correctness of the patch, one can try to show that it's impossible to falsify the patch. The patch could furthermore only be false if it would sort in a case where sorting isn't really needed. I had added sorting in some cases only to provide platform consistency for return values to the simulation or even JS GUI, where they might not be needed. So one could complain about that, as it's a subjective / policy / design decision. But there's not much room for arguing about that either, as JS GUI devs usually don't know what C++ code they're calling, so better have it platform consistent.

I think sorting always would make the code much shorter and less complex, but I anticipated the hypothetical criticism that there could be one user where sorting order doesn't matter and it would hurt feelings to make it few microsecond slower, so I wrote the proof into every caller. That has the effect that every caller will have to determine wisely, which isn't too bad, but it's still costing development time that might not be needed after all.

Also that the explicit sorting argument means that the caller is forced to be conscious that it's sorted upon request and thus doesn't think about adding a std::sort call afterwards, like in ColladaManager.cpp. Doesn't make a significant difference, since devs should be aware of what they do anyhow.

I think returning paths in a deterministic sorted order always is best. IO is a known slow thing, so losing a few microseconds (even a few hunderds) on that seems completely irrelevant and _should_ be completely irrelevant.

So my advice is sorting always, structurally, and if that's slow you need custom caching, and that's it.

In D1756#71263, @wraitii wrote:

I think returning paths in a deterministic sorted order always is best. IO is a known slow thing, so losing a few microseconds (even a few hunderds) on that seems completely irrelevant and _should_ be completely irrelevant.
So my advice is sorting always, structurally, and if that's slow you need custom caching, and that's it.

There are few calls here where the result of the function call is only processed in the calling function and no further.
And if in these cases we don't need a deterministic order, one could argue that omitting the sort in these cases in a C++ performance maximization world is plausible.
Still seems like a diceroll so meh.

What's about wraitii suggestion:

If not, I would recommend passing an enum VFS::SORTED or something instead of true or false since C++ doesn't have named arguments

It makes sense to use a name. It'd be easier to read such code.