RFC: std.*.concept convention

[Rikki Cattermole via Digitalmars-d]

On 11/02/2015 9:00 p.m., Jakob Ovrum wrote:
> ------------
> Preface
> ------------
>
> I'd like to start by saying that this is a relatively low-impact
> enhancement in the short term, but should pay off in the long term. It
> also requires very little effort, so it is low-hanging fruit, although
> it requires some foresight to see the benefit.
>
> ------------
> Primer of type concepts for the uninitiated (skip if you know this stuff)
> ------------
>
> In D we have the idea of a type concept. Current notable concepts are
> the range concept and the container concept. The idea is that any type
> that satisfies the operations of a certain usage pattern can be said to
> satisfy a certain type concept, and thus be usable in algorithms that
> use a permutation of said usage pattern. The operations making up a type
> concept are called the primitives of the concept.
>
> For example, for a type to satisfy the input range concept, the
> following usage pattern must compile:
> ---
> R r;              // can define a range object
> if (r.empty) {}   // can test for empty
> r.popFront();     // can invoke popFront()
> auto h = r.front; // can get the front of the range of non-void type
> ---
> The three required operations for the input range concept are the front,
> empty and popFront primitives. In addition there may be certain
> restrictions on runtime behaviour; for example, `front` should never be
> called on an empty range.
>
> For convenient verification of a type satisfying a concept, we have
> concept checker templates such as isInputRange[1].
>
> ------------
> Suggestion
> ------------
>
> Lately there is a trend of splitting up modules into packages in Phobos.
> Notably, std.range and std.container have been split up into packages.
>
> Currently all the range concept checkers are defined in a module
> std.range.primitives, bundled with the UFCS implementations of the range
> primitives for in-built slice types.
>
> Containers do not (yet) have concept checkers, but I consider it likely
> we'll see them in the future, as we see more generic container
> algorithms as well as higher-order containers.
>
> Additionally, Andrei has suggested a new type RefCountedSlice!T that
> presents the same dynamic array interface of T[], but with a
> reference-counted backend in lieu of the GC backend of T[]. It is
> conceivable that generic array algorithms may want to accept either
> type, and thus the "dynamic slice" concept is born.
>
> Putting the complexity of the container concept aside; I think we should
> factor out the concept checkers from std.range.primitives and put them
> in std.range.concept and establish a convention of using modules named
> std.*.concept for concept checkers in the future. The consistency gained
> by such a convention makes type concepts easier to understand and
> commonly used module names easier to remember. If we do it now, there is
> no breakage, as the splitting of std.range has not yet been released:
> hence the otherwise clumsy timing of this suggestion.
>
> It is very little work, but anticipating complaints of bike-shedding if
> I didn't explain myself, I decided to post here first. I'd like to get
> some feedback before I file a PR.
>
> [1] http://dlang.org/phobos/std_range#isInputRange

As long as the std.concept package get's good documentation, I think its 
a damn good idea!