Hi,

by reading the documentation of std.getopt I would assume, this is a valid call

dmd -run sample.d --modelicalibs a b

``` d
import std;

void main(string[] args)
{
    string[] modelicaLibs;
    getopt(args, "modelicalibs", &modelicaLibs);
    assert(modelicaLibs == ["a", "b"]);
}
```

but it fails, as array modelicaLIbs only contains ["a"].

The std.getopt : arraySep documentation hints that it should work:
> The string used to separate the elements of an array or associative array (default is "" which means the elements are separated by whitespace).

Is my understanding wrong, or is this a bug?

Kind regards
André

On 7/14/20 7:12 AM, Andre Pany wrote:
> Hi,
> 
> by reading the documentation of std.getopt I would assume, this is a valid call
> 
> dmd -run sample.d --modelicalibs a b
> 
> ``` d
> import std;
> 
> void main(string[] args)
> {
>      string[] modelicaLibs;
>      getopt(args, "modelicalibs", &modelicaLibs);
>      assert(modelicaLibs == ["a", "b"]);
> }
> ```
> 
> but it fails, as array modelicaLIbs only contains ["a"].
> 
> The std.getopt : arraySep documentation hints that it should work:
>> The string used to separate the elements of an array or associative array (default is "" which means the elements are separated by whitespace).
> 
> Is my understanding wrong, or is this a bug?

The whitespace separator doesn't get to your program. args is:

["sample", "--modelicalibs", "a", "b"]

There is no separator in the parameter to --modelicalibs, it's just "a".

What you need to do is:

dmd -run sample.d --modilicalibs "a b"

-Steve

On Tuesday, 14 July 2020 at 11:12:06 UTC, Andre Pany wrote:
> [...]

Steven Schveighoffer already answered while I was composing this, so discarding top half.

As far as I can tell the default arraySep of "" splitting the argument by whitespace is simply not the case.

> https://github.com/dlang/phobos/blob/master/std/getopt.d#L923

    // ...
    else static if (isArray!(typeof(*receiver)))
    {
        // array receiver
        import std.range : ElementEncodingType;
        alias E = ElementEncodingType!(typeof(*receiver));

        if (arraySep == "")
        {
            *receiver ~= to!E(val);
        }
        else
        {
            foreach (elem; val.splitter(arraySep).map!(a => to!E(a))())
                *receiver ~= elem;
        }
    }

So you will probably want an arraySep of " " if you want --modelicalibs "a b".

On Tuesday, 14 July 2020 at 13:40:44 UTC, Steven Schveighoffer wrote:
>
> The whitespace separator doesn't get to your program. args is:
>
> ["sample", "--modelicalibs", "a", "b"]
>
> There is no separator in the parameter to --modelicalibs, it's just "a".
>
> What you need to do is:
>
> dmd -run sample.d --modilicalibs "a b"
>
> -Steve

I thought this was the solution too, but when I actually tried it, I got `modelicaLibs == ["a b"]` and the assertion still failed.

On 7/14/20 9:51 AM, Anonymouse wrote:
> On Tuesday, 14 July 2020 at 11:12:06 UTC, Andre Pany wrote:
>> [...]
> 
> Steven Schveighoffer already answered while I was composing this, so discarding top half.
> 
> As far as I can tell the default arraySep of "" splitting the argument by whitespace is simply not the case.
> 
>> https://github.com/dlang/phobos/blob/master/std/getopt.d#L923
> 
>      // ...
>      else static if (isArray!(typeof(*receiver)))
>      {
>          // array receiver
>          import std.range : ElementEncodingType;
>          alias E = ElementEncodingType!(typeof(*receiver));
> 
>          if (arraySep == "")
>          {
>              *receiver ~= to!E(val);
>          }
>          else
>          {
>              foreach (elem; val.splitter(arraySep).map!(a => to!E(a))())
>                  *receiver ~= elem;
>          }
>      }
> 
> So you will probably want an arraySep of " " if you want --modelicalibs "a b".

Hm... that looks like it IS actually expecting to do what Andre wants. It's adding each successive parameter.

If that doesn't work, then there's something wrong with the logic that decides whether a parameter is part of the previous argument or not.

Please file a bug.

-Steve

On 7/14/20 10:05 AM, Steven Schveighoffer wrote:

> Hm... that looks like it IS actually expecting to do what Andre wants. It's adding each successive parameter.
> 
> If that doesn't work, then there's something wrong with the logic that decides whether a parameter is part of the previous argument or not.
> 
> Please file a bug.

Belay that, the behavior is as designed, I think the issue is the documentation.

If arraySep is "", then it's not "separation by whitespace", but rather you must repeat the parameter and each one is appended to the array:

dmd -run sample.d --modelicalibs a --modelicalibs b

If you want to specify all the parameters in one, you have to provide an arraySep.

The documentation needs updating, it should say "parameters are added sequentially" or something like that, instead of "separation by whitespace".

-Steve

On 7/14/20 10:22 AM, Steven Schveighoffer wrote:
> The documentation needs updating, it should say "parameters are added sequentially" or something like that, instead of "separation by whitespace".

https://github.com/dlang/phobos/pull/7557

-Steve

On Tuesday, 14 July 2020 at 14:33:47 UTC, Steven Schveighoffer wrote:
> On 7/14/20 10:22 AM, Steven Schveighoffer wrote:
>> The documentation needs updating, it should say "parameters are added sequentially" or something like that, instead of "separation by whitespace".
>
> https://github.com/dlang/phobos/pull/7557
>
> -Steve

Thanks for the answer and the pr. Unfortunately my goal here is to simulate a partner tool written  in C/C++ which supports this behavior. I will also create an enhancement issue for supporting this behavior.

Kind regards
Anste

On Tuesday, 14 July 2020 at 15:48:59 UTC, Andre Pany wrote:
> On Tuesday, 14 July 2020 at 14:33:47 UTC, Steven Schveighoffer wrote:
>> On 7/14/20 10:22 AM, Steven Schveighoffer wrote:
>>> The documentation needs updating, it should say "parameters are added sequentially" or something like that, instead of "separation by whitespace".
>>
>> https://github.com/dlang/phobos/pull/7557
>>
>> -Steve
>
> Thanks for the answer and the pr. Unfortunately my goal here is to simulate a partner tool written  in C/C++ which supports this behavior. I will also create an enhancement issue for supporting this behavior.
>
> Kind regards
> Anste

Enhancement issue:
https://issues.dlang.org/show_bug.cgi?id=21045

Kind regards
André

On Wednesday, 15 July 2020 at 07:12:35 UTC, Andre Pany wrote:
> On Tuesday, 14 July 2020 at 15:48:59 UTC, Andre Pany wrote:
>> On Tuesday, 14 July 2020 at 14:33:47 UTC, Steven Schveighoffer wrote:
>>> On 7/14/20 10:22 AM, Steven Schveighoffer wrote:
>>>> The documentation needs updating, it should say "parameters are added sequentially" or something like that, instead of "separation by whitespace".
>>>
>>> https://github.com/dlang/phobos/pull/7557
>>>
>>> -Steve
>>
>> Thanks for the answer and the pr. Unfortunately my goal here is to simulate a partner tool written  in C/C++ which supports this behavior. I will also create an enhancement issue for supporting this behavior.
>>
>> Kind regards
>> Anste
>
> Enhancement issue:
> https://issues.dlang.org/show_bug.cgi?id=21045
>
> Kind regards
> André

An enhancement is likely to hit some corner-cases involving list termination requiring choices that are not fully generic. Any time a legal list value looks like a legal option. Perhaps the most important case is single digit numeric options like '-1', '-2'. These are legal short form options, and there are programs that use them. They are also somewhat common numeric values to include in command lines inputs.

I ran into a couple cases like this with a getopt cover I wrote. The cover supports runtime processing of command arguments in the order entered on the command line rather than the compile-time getopt() call order. Since it was only for my stuff, not Phobos, it was an easy choice: Disallow single digit short options. But a Phobos enhancement might make other choices.

IIRC, a characteristic of the current getopt implementation is that it does not have run-time knowledge of all the valid options, so the set of ambiguous entries is larger than just the limited set of options specified in the program. Essentially, anything that looks syntactically like an option.

Doesn't mean an enhancement can't be built, just that there might some constraints to be aware of.

--Jon