Another day in the ordeal of cartesianProduct

[Peter Alexander]

On Saturday, 27 October 2012 at 13:06:09 UTC, Andrei Alexandrescu 
wrote:
> On 10/27/12 8:23 AM, Peter Alexander wrote:
>> Retrofitting some sort of structure to templates will be a 
>> Herculean
>> task, but I think it has to happen. It is clear to me that the
>> development process we use now (write the template, try a few
>> instantiations, pray) is unsustainable beyond simple templates.
>
> It's not clear to me at all. The mechanism works very well and 
> is more expressive than alternatives used by other languages.

I'm not sure I can agree it works well.

For example, here's what happened with bug 8900 mentioned in the 
OP:

std.range.zip creates a Zip object, which has a Tuple member. 
Tuple has a toString function, which calls formatElement, which 
calls formatValue, which calls formatRange, which (when there's a 
range of characters) has a code path for right-aligning the 
range. To right-align the range it needs to call walkLength.

The problem arises when you zip an infinite range of characters 
e.g. repeat('a').

Before pull request 880, walkLength accepted infinite ranges and 
just returned size_t.max. Pull request 880 added a constraint to 
walkLength to stop it accepting infinite ranges. Suddenly, you 
cannot zip a range of infinite chars because of a seemingly 
unrelated change.

This would have been caught if there was a unit test, but there 
wasn't, and as Dijkstra says, "testing can be a very effective 
way to show the presence of bugs, but it is hopelessly inadequate 
for showing their absence." There are probably other places that 
are broken, and many changes in the future will just introduce 
more bugs without tests.

Maybe we have different standards for "working well", but to me 
at least, this isn't what "working well" looks like.

Working well in this case would look like this:

- The person that put together pull request 880 would add the 
template constraint to walkLength.
- On the next compile he would get this error: "formatRange 
potentially calls walkLength with an infinite range." (or 
something along those lines).
- The person fixes formatRange, and all is well.

No need for unit tests, it's all caught as soon as possible 
without need for instantiation.