Optional arguments to allow future extensions of standard library

[hholst80]

How does v handle optional arguments? Is the pattern to consume a configuration struct? I kind of don't see that as flexible or extendable. Maybe it is a non-goal but I think the upside of optional arguments is not as costly compared to the benefits they bring.

In a hypothetical situation where say time.now() would be extended to define the resolution (should ns be included or not) there is no good way I see to do that right now, without introducing a new time.now_second_resolution() function. An alternative if v had optional arguments would be time.now(.second_resolution) as an optional enum with a default that would preserve the current behavior.

The other alternative would be to enforce a config to all methods that potentially would be extended.

time.now(now_config) where now_config := NowConfig{...} is a struct with defaults that preserves the current behavior of now. A config with defaults would serve the same purpose as optional arguments, but its quite a bit more "obstructive" certainly in my toy example above. Unless we could ignore to define a config struct perhaps, and have a default struct passed implicitly which is basically optional argument (in the singular).

[JalonSolov]

V handles optional arguments via https://github.com/vlang/v/blob/master/doc/docs.md#trailing-struct-literal-arguments

As long as the struct is the only parameter (and is tagged with the@[params] attribute), you can leave it out completely and just get the defaults.

[hholst80]

I suppose that time.now() could be extended this way in a source compatible way to allow a TimeNowConfig parameter struct? (I am not suggesting that for real, just a straw man use case.)

[JalonSolov]

That's the simplest way to extend it, certainly. And it can be done on every routine in vlib (that doesn't already have a params struct).