Has someone encountered similar issues with -cov?

[Steven Schveighoffer via Digitalmars-d]

On 7/1/16 4:08 PM, Andrei Alexandrescu wrote:
> On 7/1/16 2:46 PM, Steven Schveighoffer wrote:
>> On 7/1/16 2:15 PM, Andrei Alexandrescu wrote:
>>> On 7/1/16 2:05 PM, Chris wrote:
>>>> On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
>>>>> https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
>>>>
>>>> I fail to see why it should not mark it as uncovered in the `cube`
>>>> example. After all the statement is never covered, because `do`
>>>> executes
>>>> before the condition in `while` is checked. Unless you mean it
>>>> should be
>>>> optimized away by the compiler, which in turn has nothing to do with
>>>> -cov.
>>>
>>> Yah it's a bit subtle. That line is in fact pure punctuation, so even
>>> though there's no flow through it that's totally fine (as much as you
>>> wouldn't expect a line with a "}" to show no coverage). -- Andrei
>>
>> Suppose one wants to check if you've covered all cases inside the while
>> loop (with breaks or returns). Then, one would WANT to see 0 coverage
>> there (non-zero coverage would mean an error in logic).
>>
>> To remove that feedback would mess up someone else's use case.
>
> This argument is phony. Unconvinced. -- Andrei

I don't use while(0), so I have to invent a hypothetical use case. It's 
not phony. I could just as easily say that your coding style is 
illegitimate, and you should use while(true) instead (and thereby get 
100% coverage analysis). But I'm not saying that.

There is a legitimate difference between breaking out of the while loop 
using breaks, and breaking out using the while(0) condition. Why do you 
want coverage analysis to ignore that difference? Why would someone 
else's use case that relies on executing or not executing while(0) be 
invalid?

-Steve