On Wed, Dec 16, 2015 at 06:46:46PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/16/2015 06:29 PM, H. S. Teoh via Digitalmars-d wrote: > >Allow overloading by number of arguments, maybe? (This sounds > >suspiciously like a slippery slope, though...) > > That'll have trouble with $0 and $+.
Not if we adopt the rule that if there are more arguments than the overload with the most number of arguments, then that overload is invoked. OTOH, I just realized that macro definitions don't indicate the number of parameters. Perhaps overloads should be defined with different syntax? E.g.: // old syntax: NON_OVERLOADABLE = blah $0 blah $1 blah $+ // new (additional) syntax: OVERLOADABLE(a) = blah $a blah OVERLOADABLE(a,b) = blah $a blah $b blah OVERLOADABLE(a,b,c) = blah $a blah $b blah $c blah Having parameter names will also help readability; currently, with $1, $2, $3 it's non-obvious what each parameter is supposed to be without reading the macro definition. The old parameterless syntax then can be reserved for truly variadic macros. > >Or allow argument list slicing, D-style? Not sure if this would > >solve all the necessary cases. > > Overall I think a few additions to the macro engine could be very > beneficial. E.g. while working on dconf.org I could use $(IF a, b, c) > to expand b if a is nonempty and c otherwise. [...] This will make ddoc Turing-complete, which may or may not be what you want. :-D (Although IIRC ddoc does impose a limit on recursion depth, so perhaps it won't *quite* be Turing complete just yet...) T -- I think the conspiracy theorists are out to get us...