(Also comparing them with C++0x concepts.)

http://www.digitalmars.com/d/2.0/cpp0x.html#concepts

http://www.digitalmars.com/d/2.0/concepts.html

Essentially, I think we cover the necessary ground with an order of magnitude simpler system.

Walter Bright wrote:
> 
> (Also comparing them with C++0x concepts.)
> 
> http://www.digitalmars.com/d/2.0/cpp0x.html#concepts
> 
> http://www.digitalmars.com/d/2.0/concepts.html
> 
> Essentially, I think we cover the necessary ground with an order of magnitude simpler system.

Maybe you should provide an example somewhere of how to translate this basic C++0x example into D:

----
auto concept LessThanComparable<typename T> {
    bool operator<(T, T);
};

template<LessThanComparable T>
const T& min(const T& x, const T& y) {
    return x < y? x : y;
}
----

--bb

Bill Baxter wrote:
> Maybe you should provide an example somewhere of how to translate this basic C++0x example into D:
> 
> ----
> auto concept LessThanComparable<typename T> {
>     bool operator<(T, T);
> };
> 
> template<LessThanComparable T>
> const T& min(const T& x, const T& y) {
>     return x < y? x : y;
> }
> ----


See the isAddable example.

Walter Bright:
> http://www.digitalmars.com/d/2.0/concepts.html

They look nice (but I may use a bigger list of examples to understand how they can be used). What can they do that can't be done with the things already present?

bool isprime(int n) { ... }
template Foo(int N) {
    static assert (isprime(N), "error");
    ...
}


template Foo(int N) {
    static if (N & 1) {
        // A code
    } else {
        // B code
}
Foo!(3)    // instantiates Foo with A code
Foo!(64)   // instantiates Foo with B code

Bye,
bearophile

Walter Bright wrote:
> Bill Baxter wrote:
>> Maybe you should provide an example somewhere of how to translate this basic C++0x example into D:
>>
>> ----
>> auto concept LessThanComparable<typename T> {
>>     bool operator<(T, T);
>> };
>>
>> template<LessThanComparable T>
>> const T& min(const T& x, const T& y) {
>>     return x < y? x : y;
>> }
>> ----
> 
> 
> See the isAddable example.

A more natural way to declare required functions would be nice.

First of all, about the isAddable example, can't you just use T.init instead of writing an anonymous delegate?  Like
   __traits(compiles, T.init + T.init)


Anyway, for a less trivial example I think that becomes pretty cumbersome.  E.g.:

concept Stack<typename X> {
  typename value_type;
  void push(X&, const value_type&);
  void pop(X&);
  value_type top(const X&);
  bool empty(const X&);
};

is going to translate to something like this?:

template Stack(T)
{
    const Stack =
        is(T.value_type) &&
        __traits(compiles, (T t, T.value_type v) { push(t, v); }) &&
        __traits(compiles, (T t) { pop(t); }) &&
        __traits(compiles, (T t) { top(t); }) &&
        is(typeof(top(T.init))==T.value_type) &&
        __traits(compiles, (T t) { empty(t) }) &&
        is(typeof(empty(T.init))==bool);
}

I hope you can work out a way to give this a more natural syntax, like Concepts will have in C++0x.
----

An unrelated comment is that I don't think it is relevant or respectful to compare the lengths of the specs.  The spec for Concepts that you link to includes many many more in depth examples than the D spec does.  It's an apples vs oranges comparison.  So 5 pages vs 49 pages really doesn't have much meaning at all.

--bb

Walter Bright wrote:
> 
> (Also comparing them with C++0x concepts.)
> 
> http://www.digitalmars.com/d/2.0/cpp0x.html#concepts
> 
> http://www.digitalmars.com/d/2.0/concepts.html
> 
> Essentially, I think we cover the necessary ground with an order of magnitude simpler system.

Very much so, brilliant! But what about concept maps, the suggestion is to use proxy objects but won't that be very cumbersome? Aren't concept maps important enough?

btw. I think it does more than cover necessary ground, with CTFE constraints are more powerful, though that may have limited use.

bearophile wrote:
> Walter Bright:
>> http://www.digitalmars.com/d/2.0/concepts.html
> 
> They look nice (but I may use a bigger list of examples to understand how they can be used). What can they do that can't be done with the things already present?
> 
> bool isprime(int n) { ... }
> template Foo(int N) {
>     static assert (isprime(N), "error");
>     ...
> }
> 
> 
> template Foo(int N) {
>     static if (N & 1) {
>         // A code
>     } else {
>         // B code
> }
> Foo!(3)    // instantiates Foo with A code
> Foo!(64)   // instantiates Foo with B code
> 
> Bye,
> bearophile

For one thing they get away from the big-long-if-statements.  That means you can extend a template in a different place, so the code is less brittle.

-Joel

For me, this is the big difference between them:

Semantic analysis of template bodies:
 - D: Lazy (done at instantiation time)
 - C++0x: Eager (done at definition time)

I want to get errors in the template itself, not just know that I've done something wrong in my template when some user discovers a bug in it. This will also enable IDE support for templates.

Walter Bright a écrit :
> 
> (Also comparing them with C++0x concepts.)
> 
> http://www.digitalmars.com/d/2.0/cpp0x.html#concepts
> 
> http://www.digitalmars.com/d/2.0/concepts.html
> 
> Essentially, I think we cover the necessary ground with an order of magnitude simpler system.

Bill Baxter wrote:
> A more natural way to declare required functions would be nice.
> 
> First of all, about the isAddable example, can't you just use T.init instead of writing an anonymous delegate?  Like
>    __traits(compiles, T.init + T.init)

I think you're right.

> Anyway, for a less trivial example I think that becomes pretty cumbersome.  E.g.:
> 
> concept Stack<typename X> {
>   typename value_type;
>   void push(X&, const value_type&);
>   void pop(X&);
>   value_type top(const X&);
>   bool empty(const X&);
> };
> 
> is going to translate to something like this?:
> 
> template Stack(T)
> {
>     const Stack =
>         is(T.value_type) &&
>         __traits(compiles, (T t, T.value_type v) { push(t, v); }) &&
>         __traits(compiles, (T t) { pop(t); }) &&
>         __traits(compiles, (T t) { top(t); }) &&
>         is(typeof(top(T.init))==T.value_type) &&
>         __traits(compiles, (T t) { empty(t) }) &&
>         is(typeof(empty(T.init))==bool);
> }
> 
> I hope you can work out a way to give this a more natural syntax, like Concepts will have in C++0x.

You're the first I've heard say that Concepts have a natural syntax! But let me try:

template Stack(T)
{
    const Stack =
        __traits(compiles,
	    (T t)
	    {	T.value_type v = top(t);
		push(t, v);
		pop(t);
		if (empty(t)){}
	    });
}

The idea is that the desired operations are expressed as operations, rather than as function signatures.

> An unrelated comment is that I don't think it is relevant or respectful to compare the lengths of the specs.  The spec for Concepts that you link to includes many many more in depth examples than the D spec does.  It's an apples vs oranges comparison.  So 5 pages vs 49 pages really doesn't have much meaning at all.

I wished to make the point that D constraints build on what one already knows - how to write a D expression. Concepts, on the other hand, have a major new syntax and semantic thing that must be learned. Perhaps I expressed the point badly, do you have a suggestion?

Lutger wrote:
> Very much so, brilliant! But what about concept maps, the suggestion is to use proxy objects but won't that be very cumbersome? Aren't concept maps important enough?

I think I understand concept maps, but I don't understand what the compelling use case for their existence is.