On Mon, Sep 02, 2013 at 09:28:37PM +0200, Ramon wrote:
> I see strong points on both sides. Maybe it would be a good thing to
> really have two versions with the second one ("getOpts") getting the
> options in arrays (as introduced above). Like that the "simple"
> version we have now could, besides some minor corrections, stay like
> it is and not disturb existing programs using it. The second version
> would be the "bigger" one with help, valid ranges, eval funcs, and
> other goodies as identified by a crowd discussed wish list (and
> "auto help print" controlled e.g. by a flag).
[...]
Actually, I think it's possible to please both sides with a single
implementation. If we use what was suggested, and add an optional string
parameter per option to serve as a help string, then that takes care of
the auto help functionality.
For checking ranges and stuff, we already support delegates passed to
getopt, for example:
void main(string[] args) {
int size;
getopt(args,
"-s", (int s) {
enforce(s >= 10 && s < 20);
size = s;
}
);
}
So we just need to provide a few commonly-used range-checking option
parsers and we're good to go. For example, with the proposed
enhancements, we could write:
void main(string[] args) {
enum A { Aa, Ab, Ac };
A a;
int size;
getopt(args,
"-a", &a, "Type of data to generate",
"-s", checkBounds(&size, 10, 20), "Size of input"
);
}
Where checkBounds (that is, std.getopt.checkBounds) is defined something
like this:
auto checkBounds(T)(T* targetVar, T lowerBound, T upperBound) {
// Returns a delegate usable by the current version of
// getopt.
return (string optValue) {
auto val = to!T(optValue);
enforce(val >= lowerBound && val < upperBound);
*targetVar = val;
};
}
Other similar helpers that can parse lists, arrays, etc., can be
provided by std.getopt, so that user code will never have to
re-implement any of this boilerplate by hand.
T
--
IBM = I'll Buy Microsoft!
