Fix runApplication handling of unrecognized command-line args

[joseph-wakeling-frequenz]

runApplication takes an args_out parameter which, if non-null, is supposed to be set to match unrecognized command-line args. However, the parameter is never passed to finalizeCommandLineOptions, which will therefore log an error and throw an exception if any command line arguments are unrecognized.

This patch fixes the oversight, ensuring that runApplication will correctly populate a non-null args_out parameter with unrecognized command-line arguments, and not throw an exception in this case.

[joseph-wakeling-frequenz]

As a side remark: this design seems a bit intrusive in how it handles arguments. I get that the intent must be to allow vibe-core to ensure that it gets its hands on all its potential arguments before anyone else does (so someone can't getopt and clash with one of vibe's needed args), but as currently designed it looks like it's not readily possible to unittest, which is not great.

[joseph-wakeling-frequenz]

What's not entirely clear to me is the intended usage of this args_out parameter, given that runApplication takes us in to the event loop and so marks the logical "end" of any main function (apart from post-eventloop-shutdown reporting). It would be good to have this documented.

I can make guesses about what that intended usage is, but it'd be good to have it clearly explained by someone behind the design of this code.

[s-ludwig]

I agree about the lack of beauty of this functionality, it's a relic of the beginnings where the primary idea was to replicate the scripting language experience and to avoid any boilerplate code during initialization. The args_out followed later to work around its closed nature.

For runApplication, the only way to access the returned arguments would be in a separate task. I don't think this is actually used anywhere, but there are places where finalizeCommandLineArguments and runEventLoop are used explicitly. I think I just added the parameter for completeness sake when runApplication got introduced, without really thinking enough about it.

An immediate improvement would be to add a second overload of runApplication that takes a scope void delegate(string[]) nothrow @safe instead, so that it is at least clear when those arguments can be accessed. Long-term, I'd like to get rid of the command line argument handling altogether (moving it to an independent opt-in package, e.g. vibe-commandline).

[joseph-wakeling-frequenz]

@s-ludwig makes sense, thanks for giving the context and history.

If there's long-term scope for some significant re-thinking of how vibe-core works, I might have some interest in following up on that. I won't commit to anything now, but I may drop you a line some time in the future if this becomes more than just a line of thought.

[s-ludwig]

I may be overlooking something now, but I think it really is just the command line handling, the main part of vibe-core is meant to remain in its current form for the time being. Do you have any thoughts about other areas?

[joseph-wakeling-frequenz]

Nothing too explicit for now, as it's quite a speculative line of thought which needs to be properly researched before offering an opinion. But the core of it is about ensuring that we have a very nice, flexible, and simple-to-use async-io-based task system, with easy interactions with stuff like streams.

There are a few different implementations of that -- vibe.d, the task framework in sociomantic's ocean library, weka.io's mecca.reactor -- and it could be good to try to have a review of features, limitations, assumptions, etc. to see whether we can boil all those needs down to a common core.