Some feedback on the website.

[H. S. Teoh via Digitalmars-d]

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...