On Thursday, 6 February 2014 at 01:01:59 UTC, Chris Williams
wrote:
1. You only know what the target is that you have to hit by
looking at their source. Or, the person who wrote the template
checker needs to, effectively, rewrite their check as a
document comment. (E.g. see std.range isInputRange)
The documentation must explain everything the concept entails. It
is not acceptable that the user is forced to look at Phobos'
source code to figure out a public interface. If that's forced
anywhere in Phobos, it's a bug.
While it's not hard to remember that an input range needs a
boolean property `empty`, a property `front` of any non-void type
and a void `popFront()` method, I agree that a more formalized
solution of documenting concepts would be an improvement. The
current method of replicating a documented version of the source
code in the documentation is a bit icky, as the user has to
*derive* how to write their types based on that code snippet.
2. Writing functions which are restricted to a particular type
is long-winded and subsequently error-prone. (E.g. all
implementations of std.random uniform() should check
isUniformRNG(), when they accept an external generator)
Perhaps error prone, but in terms of conciseness there aren't
that many differences:
---
// Concepts (current approach)
T uniform(T, RNG)(ref RNG rng) if (isUniformable!T &&
isUniformRNG!RNG);
// Interfaces
T uniform(T)(IUniformRNG rng) if (isUniformable!T);
// Protocols
T uniform(T : IUniformable, RNG : IUniformRNG)(ref RNG rng);
---
It seems only the interface approach can claim being less error
prone.
I think that the advantages that are added by template-based
compilability checks can be gained without losing flexibility
if we add a more lenient interface definition, like:
duck InputRange {
bool empty; // can be a function or not. Doesn't care. Anyone
using it must avoid using () syntax
auto front; // Doesn't care what the return type is so long
as it's non-void
void next; // Cannot return a value
}
It is usually called a "protocol".
