On Wednesday, 6 April 2016 at 20:42:27 UTC, Lucian Radu
Teodorescu wrote:
On Wednesday, 6 April 2016 at 14:54:18 UTC, Puming wrote:
On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei
Alexandrescu wrote:
[...]
Interesting. I've thinking about concepts too. Hopefully they
could come into D. Actually, I think concept and interfaces
could be combined into one feature. An interface is just a
special case of a concept, saying its implementer should have
the matching function signatures.
In my opinion implementing concepts in terms of interfaces is
more restrictive than implementing them as boolean predicates.
You cannot create interfaces based on existence of attributes,
on existence of dependent types or on the existence of extern
function that apply to your types. Moreover, you cannot create
concepts based on the compile-time values associated with your
type.
Well, I meant the opposite, interfaces be implemented with
concept.
So in my opinion, interface is just a spcecial case of concept.
I'm in the same park with you.
See
https://github.com/venus-lang/venus/blob/master/docs/reference/trait.md where I call concept 'trait'.
One basic example, from C++, is that you cannot create a
concept that distinguishes between vector<int> and
vector<bool>, as they theoretically should have the same
interface.
The main uses of concepts are in my view most of the time
related to dependent types. I would like to have an InputRange
concept that will also tell me the type of the elements I can
read from it.
Exactly, that is well I found InputRange in D awkward, where I
have to specify a long predicate everywhere in my function
definiations of a call chain.
Implementing concepts as predicates, give you much more
freedom. I would argue that you can represent many more
concepts with predicates. Not only you can represent all the
"has-a" relations, but you can also place conditions on the
compile-time values that your types might have, and how that
class may be used.
Yes, indeed.
My two cents,
LucTeo