std.getopt suggestion

[Andrei Alexandrescu]

On 9/29/11 11:35 PM, Jacob Carlborg wrote:
> On 2011-09-29 22:40, Andrei Alexandrescu wrote:
>> On 9/29/11 11:54 AM, Jonathan M Davis wrote:
>>> On Thursday, September 29, 2011 11:39 Andrei Alexandrescu wrote:
>>>> I don't think it would improve the module design, even without
>>>> considering cost of change. It just adds useless clutter.
>>>
>>> Well, out of those who have responded in this thread, you're the only
>>> one who
>>> thinks that. Everyone else has been in favor of either making those
>>> config
>>> options passable to getopt or in favor of putting getopt on a struct
>>> which
>>> holds the those config options (with a free function which uses the
>>> init value
>>> of the struct for the common case).
>>
>> Upon further thinking, I'm even less sure than before that that's a good
>> idea.
>>
>>> And yes, that's an argument by ad populum
>>> (or whatever the exact name is), but what's considered "clutter" is
>>> subjective.
>>
>> Clutter is stuff on top of the baseline that doesn't pull its weight.
>> The baseline is:
>>
>> "In order to get a command-line options for your program, you must
>> import std.getopt, define the variables holding the options, and call a
>> function to fill them."
>
> How can you miss some many times that with the suggestion there will
> still be a free function that you can call if you want to use the
> default settings.

If anyone missed anything, it's you who missed my not missing it :o).

Andrei