On Wednesday, February 11, 2015 08:00:53 Jakob Ovrum via Digitalmars-d wrote: > 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.
I think that the idea is a good one, and this isn't the first time that it's been suggested, but I think that it would be more consistent if we used the term traits rather than the term concepts. We really haven't been using the term concepts for anything in D, and instead have been heavily using the term traits for what you're talking about - e.g. isInputRange is considered to be a trait. In addition, we probably don't want to confuse them with C++'s concepts. Much as they're similar, they're quite not the same thing. So, if we go this route, I think that it should be std.*.traits and not std.*.concept. But I think that the idea is a solid one, particularly because it allows us to import the traits for use in template constraints without having to import any of the functions related to them, and then those functions can be imported as appropriate with local imports. - Jonathan M Davis
