On 6/6/2013 7:40 PM, Jonathan M Davis wrote:
> I've definitely used it before (particularly when originally writing
> std.datetime), but it's not something that I remember to use often enough. I'm
> thorough enough with my unit tests that I tend to assume that I have fully
> coverage (which I probably do in most cases), but it would be much safer to
> actually check. Having at least the percentage spit out as part of the build
> step would certainly be useful though, since then I could see when it
> changes.. I wonder if I should set it up so that my unit test builds do that.

If you look in phobos' win32.mak, you'll see some rules that give a minimum cov percentage that each module must pass. It's meant to detect if the coverage is backsliding without requiring any ongoing effort.

On 6/6/2013 9:34 PM, Brad Roberts wrote:
> On 6/6/13 6:12 PM, Walter Bright wrote:
>
>> and I'm the only one I know of that uses it.
>
> You really need to get out of the habit of associating "I can't remember people
> telling me they use something" and "no one uses it".
>
>     1) your memory isn't perfect.
>
>     2) just because you're not aware it's happening doesn't mean it isn't.
>
>     3) likely lots of other reasons, but come on, 1 and 2 are more than
> sufficient to kill the phrase.
>
> Yeah, I know you couched it with "I know of" this time, but the pattern is
> pretty silly regardless.  This community is awfully myopic when it comes to use
> of personal history and mapping it onto everyone else's behavior.

A pretty good metric of some feature being used is the frequency it comes up in discussion here and the action it sees in bugzilla.

There are two obvious reasons why a feature would not have much buzz:

1. it works perfectly
2. it isn't being used

Value Range Propagation is a pretty good example of (1). Sadly, I suspect -cov is (2).

I'd be happy to be wrong about that.

On 6/6/2013 11:30 PM, Peter Williams wrote:
> I use it to make sure that my unittests are complete.

Awesome!

-cov is also useful for:

1. debugging - if your unittests can't seem to cover certain lines, those lines might indicate a bug

2. performance - giving usage counts of lines tells you where the 'hot' paths are, and those can be hand-tuned

It's also quite possible to have the compiler read the coverage report, use it to identify the hot paths, and rearrange the code while optimizing so that the hot paths have the fewest branches. Profile guided optimization, if you will.

> Peter
> PS It would be nice if it printed the overview (i.e. % complete line) to stdout
> as well as sticking it in the coverage file report.

Please file this as an enhancement request on bugzilla.

On 6/6/2013 10:04 PM, Andrei Alexandrescu wrote:
> I'm carefully mentioning "entire applications" every time I got a chance. It's
> not working.

As Jonathan mentioned, I don't see how this can work with shared libraries (especially dynamically loaded ones), as you cannot know what the entire application is.

deadalnix mentioned enforcing 'export' on classes exposed to shared libraries, but then aren't we back to expecting user annotation rather than doing things automatically?

On 6/6/2013 10:14 PM, Andrei Alexandrescu wrote:
> I don't buy all that "humans aren't rational" stuff.

I don't either, but I don't think that was my point.

My point is that a language where -O delivers the performance is preferable to a language that you have to do careful annotations and run extra tools on to get it.

We discussed a while back an experimental Java compiler where annotations were used to signify uniqueness, etc. The compiler was a technical success, but the researcher was not very successful in getting users to use the annotations.

This is why I am pushing for D doing attribute inference as much as possible, rather than expecting people to annotate carefully. I believe we are much more likely to be successful with the former approach.

I'd very much prefer an auto-finalize mechanical solution.

BTW, dustmite and rdmd are great tools. I'm happy to have been proven wrong about them.

On 06/07/2013 09:22 AM, Walter Bright wrote:
> ...
> There are two obvious reasons why a feature would not have much buzz:
>
> 1. it works perfectly
> 2. it isn't being used
>
> Value Range Propagation is a pretty good example of (1). Sadly, I
> suspect -cov is (2).
>
> I'd be happy to be wrong about that.
>

You are certainly wrong about the value range propagation part. The transformers for the bitwise operators are not the best possible.

ubyte x = ((y&252)^2)+1;

The above term can be easily proven to fit into ubyte by just using an analysis of the ranges of its subterms, yet DMD rejects it.

On Friday, 7 June 2013 at 07:42:58 UTC, Walter Bright wrote:
> My point is that a language where -O delivers the performance is preferable to a language that you have to do careful annotations and run extra tools on to get it.

Depends on target audience. Some want tight control over resulting binary. At one of my jobs full scale performance test where run on every added feature and bug-fix block - mostly because even minor change to alignment to cache lines could have resulted in an observable performance drop. But that is not mainstream attitude for sure.

On Fri, 07 Jun 2013 07:20:12 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/7/13 12:34 AM, Brad Roberts wrote:
>> On 6/6/13 6:12 PM, Walter Bright wrote:
>>
>>> and I'm the only one I know of that uses it.
>>
>> You really need to get out of the habit of associating "I can't remember
>> people telling me they use something" and "no one uses it".
>
> I concur. That, and "When I was at Boeing" :o).

Aw, I like those. I tend to think of it as Walter sitting with a beard,
pipe in hand, telling stories to his grandchildren.

-- 
Simen

On Friday, 7 June 2013 at 07:22:18 UTC, Walter Bright wrote:
> A pretty good metric of some feature being used is the frequency it comes up in discussion here and the action it sees in bugzilla.
>
> There are two obvious reasons why a feature would not have much buzz:
>
> 1. it works perfectly
> 2. it isn't being used
>
> Value Range Propagation is a pretty good example of (1). Sadly, I suspect -cov is (2).
>
> I'd be happy to be wrong about that.

Or it just isn't used much compared to other things and works well enough when it is.

For what it's worth, there are a few bugs on Bugzilla about -cov, so it is being used.

On Friday, 7 June 2013 at 10:35:12 UTC, Peter Alexander wrote:
> Or it just isn't used much compared to other things and works well enough when it is.
>
> For what it's worth, there are a few bugs on Bugzilla about -cov, so it is being used.

It is also worth saying that "-cov" is more of production tool, you start using it when you invest your efforts into long-term project. It will never get much attention while certain language bugs/issues persist that jump straight into your face when you start experimenting with small snippets. Nothing wrong with "-cov' itself here.