On 2/11/15 12:47 PM, Brad Anderson wrote:
On Wednesday, 11 February 2015 at 08:00:54 UTC, Jakob Ovrum wrote:
[snip]
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.
[snip]
+1. Makes a lot of sense to do it this way.
I prefer "concept" over "trait". I think of traits as more primitive
building blocks. With a trait you are querying information about a type.
With a concept you are fitting a type to its requirements.
My uneducated feeling is that if there's a clear dividing line as to
what is a trait and what is a concept—for instance if they have
different syntax—then it makes sense to have two names. Otherwise I
think it makes more sense to have just one. Fuzzy categorization tends
to hurt.
