On Thursday, 23 June 2016 at 23:16:23 UTC, Steven Schveighoffer
wrote:
This is a problem with optional (), not text.
A valid point. But we aren't going to have this change.
Spreading the shit doesn't make it smell good.
test takes n parameters and return a string representation of
these
parameters. returning an empty string when no parameters is
provided is
very much expected.
If it has to be valid, this is what I would expect, yes. But it
doesn't have to be valid.
The only place I can see this being useful is generic code
which itself takes a tuple.
Exactly.
The alternative is to add special case. And here you get into
the bad
design land. When some bad design is introduced it causes
problems. Now
there is the option to introduce more and more bad design to
work around
the original bad design, or adopt a principled approach. I'd
rather go
for #2 . if I wanted #1, I'd be using C++ or PHP, which both
fit that
spot better than D.
It's not a special case to require a minimum number of
parameters.
You are just pushing the problem up one level. Now every template
that call text with a sequence need to do a length check (and
none will).
The very problem is that the optional () make the argumentless
thing a special case. Special cases are like cancer, they spread.
Making more argumentless thing special cases is just making the
problem worse.
But it is pushed on somebody else, so I guess that's alright...
That reminds me of https://www.youtube.com/watch?v=aI0euMFAWF8
When the solution to a problem is adding more special casing,
you can be
sure you are not moving in the right direction.
There is already a special case for zero arguments -- a whole
static if branch, in fact.
That's an implementation detail.
string test(T...)(T args) {
auto ret = "";
foreach (a; args) {
ret ~= testImpl(a);
}
return ret;
}
Or it can be seen as the bottom turtle.
string test(T...)(T args) {
static if (args.length == 0) {
return "";
} else {
return text(a[0 .. $ - 1]) ~ textImpl(a[$ - 1]);
}
}
Anyway, looking at the implementation to figure out what the
semantic should be is completely ass backward. The implementation
should match desired semantic not the other way around.
