Proposed Enhancement: Deprecate std.conv.text With 0 Arguments

[deadalnix via Digitalmars-d]

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.