July 14, 2009
Walter Bright Wrote:
> There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts.

This seems to be the relevant pre-Frankfurt text: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf

I doubt concepts are 'dead' - from the rumors you've heard it sounds likely the 'decoupled' or 'semi-decoupled' option was chosen.

July 14, 2009
Christian Kamm:
> This seems to be the relevant pre-Frankfurt text: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf

>C++ as a language has competition -- from high-level runtimes such as JavaScript, .NET etc; from hardware such as graphics accelerators; and from C and Objective C.  Ideally, the pace of overall C++ feature development should be such as to maintain C++’s competitive position against such alternatives.<

Despite the performance of the Chrome V8 JS JIT, JavaScript isn't much a competitor to C++, they have different purposes and kind of programmers.

And graphics accelerators do little by themselves, they are there to be used from C++ too, if for example C++ improves its support for OpenCL and similar things.

"C++ feature development" sounds a little scary if you think about the too much complex implementation of lambda functions in C++0x... (And such kind of "developments" will not help C++0x face any competition from JavaScript, it's like nailing a second bigger cannon on a large tank to help it fight better against an infestation of mice).

Bye,
bearophile
July 14, 2009
bearophile wrote:
> C++0x Concepts are too much complex for the advantages they offer.
> Can't they replace Concepts with something similer like D constraints?

D (constraints) + (static if) + (pragma msg) can do everything that Concepts do but one thing - checking of the template body against the constraint. My opinion is the latter is of low importance.

Anyhow, Andrei suggested this a while back to them and was ignored.
July 15, 2009
Robert Fraser Wrote:

> ... And gets rid of SFNAE... Seriously, with restricted templates, template specializations, static if, etc., SFNAE is about as bug-prone a "feature" as we have in the language.

When reviewing Walter's recent blog on understanding templates, he pointed out that D does not have SFINAE. I haven't played around with templates enough to know if it all works as I'd expect or not.
July 15, 2009
Walter Bright wrote:
> D (constraints) + (static if) + (pragma msg) can do everything that Concepts do but one thing - checking of the template body against the constraint. My opinion is the latter is of low importance.

I have somehow the idea that D constraints and template specialization should merge.
Guess what I want to say is that instead of accepting the  compiler decision for template specialization  a constraints could be used for : "I am not the one who is able to fulfill your needs.. try this template instead."

template Foo(int N)
        if ( ( N & 1 _else_ FooOdd!(int N)... ) ) // or pattern matching
{
    ...
}
//not the world's best example, but guess it is showing the intention.
-- 
NO constraint, let Mr compiler decide which template fits. (old behavior)
July 15, 2009
BLS Wrote:
> I have somehow the idea that D constraints and template specialization should merge.

I also feel that specialization may just be a special case of constraints - with the added benefit that implicit function template instantiation works.

Is there a difference between
template Foo(T : U) {} and
template Foo(T) if(is(T : U)) {} ?

July 15, 2009
Christian Kamm wrote:
> BLS Wrote:
>> I have somehow the idea that D constraints and template specialization should merge.
> 
> I also feel that specialization may just be a special case of constraints -
> with the added benefit that implicit function template instantiation works.
> 

will see what Walter is thinking.
Maybe we can call that stuff later on ... meta generics ? Now serious , looking a bit ahead, complete templated decision trees are /at least/ imaginable.

> Is there a difference between
> template Foo(T : U) {} and template Foo(T) if(is(T : U)) {} ?
> 
erm, give me an hour or so.. :)
July 15, 2009
Christian Kamm wrote:
> BLS Wrote:
>> I have somehow the idea that D constraints and template specialization should merge.
> 
> I also feel that specialization may just be a special case of constraints -
> with the added benefit that implicit function template instantiation works.
> 
> Is there a difference between
> template Foo(T : U) {} and template Foo(T) if(is(T : U)) {} ?
> 

Yes. Constraints determine the list of candidate template declarations, but do not participate in the partial ordering of candidates to determine the 'best' match.
July 16, 2009
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:h3lkec$2k1t$1@digitalmars.com...
> Christian Kamm wrote:
>> BLS Wrote:
>>> I have somehow the idea that D constraints and template specialization should merge.
>>
>> I also feel that specialization may just be a special case of
>> constraints -
>> with the added benefit that implicit function template instantiation
>> works.
>>
>> Is there a difference between
>> template Foo(T : U) {} and template Foo(T) if(is(T : U)) {} ?
>>
>
> Yes. Constraints determine the list of candidate template declarations, but do not participate in the partial ordering of candidates to determine the 'best' match.

Pardon my ignorance, but...umm...what?


July 16, 2009
> Christian Kamm wrote:
>> Is there a difference between
>> template Foo(T : U) {} and
>> template Foo(T) if(is(T : U)) {} ?
>> 

Walter Bright wrote:
> Yes. Constraints determine the list of candidate template declarations, but do not participate in the partial ordering of candidates to determine the 'best' match.

Thanks for the explanation!

I expect the reason is that for constrained templates it is impossible to determine whether all valid template arguments for one would lead to a valid instantiation of another?