Can we drop static struct initializers?

[Bill Baxter]

On Fri, Nov 20, 2009 at 10:58 AM, Bill Baxter <wbaxter at gmail.com> wrote:
> On Fri, Nov 20, 2009 at 10:29 AM, Walter Bright
> <newshound1 at digitalmars.com> wrote:
>> Bill Baxter wrote:
>>>
>>> 1) Struct literals don't work if you have an opCall for your struct.
>>>    (Maybe that's not such a big deal now that structs have
>>> constructors?  I haven't had a chance to look into struct constructors
>>> yet...)
>>
>> Worst case, you can still construct them dynamically.
>>
>>> 2) The field:value style struct initializer is probably the closest D
>>> will ever get to named arguments.  I think perhaps it should require
>>> the struct name, and be treated as a struct literal rather than static
>>> initializer:
>>>
>>>      auto anS = S{D:4};   <=>   auto anS = S(4)
>>
>> I think we'd need a compelling use case for why this is needed.
>
> This is the main use case I have in mind:
>
> void runAlgo(Options opt);
>
> struct Options {
>    bool useFrobbing = false;
>    int numIters = 200;
>    float tolerance = 1e-4;
>    int verbosity = 0;
>    // ...
>  }
>
> runAlgo( Options{verbosity:100} );
>
> instead of
>
> Options opt;
> opt.verbosity = 100;
> runAlgo(opt);

I should say that I won't really shed a tear over loss of the current
static-only  {a:b} syntax.
But I would like to see something similar resurrected as a fully
dynamic construct for the use case of large numbers of options with
good defaults for most.

I see no reason the compiler shouldn't be able to turn

runAlgo( Options{verbosity:100} );

into

Options _tmp;
_tmp.verbosity = 100;
runAlgo( _tmp );

--bb