On Fri, Nov 20, 2009 at 10:58 AM, Bill Baxter <wbax...@gmail.com> wrote: > On Fri, Nov 20, 2009 at 10:29 AM, Walter Bright > <newshou...@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