Review of Andrei's std.benchmark

[Joseph Rushton Wakeling]

On 22/09/12 07:10, Nick Sabalausky wrote:
> I think this entire discussion serves as evidence that, at the very
> least, it needs to communicate that scope/methodology/rationale better
> that it currently does. If all of us are having trouble "getting it",
> then others certainly will too.

My feeling is that even with a good explanation in the docs, you're _still_ 
going to have a regular stream of people showing up on the mailing lists going, 
"Hey, why can't I get my preferred metric with std.benchmark??!!"

So, even if there's good reason to think their preferences are daft, it might be 
worth supporting what they want to do, just to avoid that continuous stream of 
requests.

> Aside from that, there's the second key issue: whether the
> current intended scope is sufficient. Should it be more general in
> scope and not so specialized? Personally, I would tend to think do, and
> I think that seems to the the popular notion. But I don't know for sure.
> If it should be more generalized, than does it need to be so for the
> first iteration, or can it be done later after being added to phobos?
> That, I have no idea.

This is what I was wondering, whether it's possible to take the current 
functionality but leave the door open to extending it with a different choice of 
metrics.

Under the extended version, the default metric would be as it is currently, the 
docs would explain why this default makes sense and the caveats related to other 
metrics, but ultimately if the user wanted to use them, they'd be available.

But I'd only like to see that happening if there is a "natural" path to the 
extended version rather than breaking changes or significant rewrites.