Comment #1 by peter.alexander.au — 2014-06-04T08:30:16Z
I agree, but I wonder if there's code out there relying on this?
For those that aren't aware, getopt declares these globals that can be customized (it's by design)
dchar optionChar = '-';
string endOfOptions = "--";
dchar assignChar = '=';
string arraySep = "";
I can easily imagine a windows program changing optionChar to '/' for consistency.
Not sure what to do about this...
Comment #2 by hsteoh — 2014-07-12T14:46:39Z
The "standard" solution is to create a struct that encapsulates possible configurations of getopt, and pass that as an optional first parameter:
module std.getopt;
struct GetoptConfig {
dchar optionChar = ...
string endOfOptions = ...;
... // etc.
}
module myprogram;
void main(string[] args) {
GetoptConfig cfg;
cfg.endOfOptions = ...;
cfg.getopt(args, ...);
}
But this will break existing code, though.
Comment #3 by andrei — 2015-11-03T19:18:47Z
I'll close this as vague.
Comment #4 by hsteoh — 2015-11-03T20:05:44Z
Vague?
I thought it's pretty clear what this bug is asking for: fix the implementation of getopt so that it doesn't require the use of globals. (Of course, whether or not this is worth the effort is a different story. I have a hard time imagining a case where this would be an actual problem in practice.)
Comment #5 by andrei — 2015-11-03T20:24:16Z
(In reply to hsteoh from comment #4)
> Vague?
>
> I thought it's pretty clear what this bug is asking for: fix the
> implementation of getopt so that it doesn't require the use of globals. (Of
> course, whether or not this is worth the effort is a different story. I have
> a hard time imagining a case where this would be an actual problem in
> practice.)
There's only one command line in a program and usually only one place it gets implemented. So globals don't strike me as a mistake here. Also, there's the matter of backward compatibility.
If there's a PR with an improvement, it's great to review it. But I don't think we need to keep a bug report open on it just because "globals are bad design".
Comment #6 by hsteoh — 2015-11-03T20:38:46Z
More complex programs may employ dispatch from the main program to subprograms that do option parsing on their own. (I've written such programs before.) But this is a rare use case, and even then I still don't see the use of globals in getopt() being an actual problem, so I agree with you that we can probably leave this bug closed.
I just disagree that it's "vague". :-)