C++0x Concepts - Dead?

[Charles Hixson]

Walter Bright wrote:
> aarti_pl wrote:
>> Walter Bright pisze:
>>> aarti_pl wrote:
>>>> My proposal would make meta programing in D much more intuitive 
>>>> (because of using rules - not bunch of corner cases as it is today). 
>>>> Unfortunately almost no one from NG commented on that...
>>>
>>> Thank you, but I don't see in your proposal a method that can:
>>>
>>> 1. instantiate templates only if a value argument is prime or odd.
>>>
>>> 2. instantiate templates only on a type which supports addition and 
>>> has the method foo.
>>>
>>> Note that C++ Concepts could do (2) but could not do (1).
>>
>> ad.1
>>
>> template normalizedType((T U N : U[N=size_t]) && (N & 1))
>>
>> As it is stated in proposal commas are only syntax sugar for more 
>> general form with '&&'.
> 
> How do you distinguish a type from an expression?
> 
> 
>> ad.2.
>>
>> This case is in fact the same as 1. Because of the fact that A, B, C 
>> <=> A && B && C, you can create expressions as you want just using 
>> second form with logical operators. In this case you should just use 
>> proper compile time reflection mechanism in D to get information about 
>> type properties.
> 
> class C {
>     int opAdd(C);
> }
> 
> How would I write the parameter to accept any type that supports 
> addition? I want to support int, float, C, etc., without having to 
> exhaustively enumerate them.
That's actually pretty close to what I want, I want to support any type 
that has a field or readable property named key which field supports < 
and >=.  Since I want to include various integer types I can't require 
that it support opCmp.

The way I'd been wishing was that the built-in types supported the 
pre-defined operators, such as opCmp.  (I haven't tried, but if they do 
it doesn't seem to be documented.  Eventually I'll probably get around 
to trying, but so far it's a comment in the class header.)
(If you haven't guessed, even the current template system intimidates 
me, so I generally look for other ways to do things.  I'm especially 
intimidated, among the parts that I've looked at, by the rules for 
instantiation of a template type.  It probably takes me half an hour 
each time I do it, and I'm never certain I've done it correctly until 
the program either works or doesn't work.)

I REALLY appreciate syntactic regularity.  I like being able to leave 
out empty parentheses. And I'd really like it if things like opCmp were 
available for the built-in types (although, I don't think opCmp should 
be defined for the complex numbers).

Actually, I'd like it if one could build classes that inherited from the 
built-in types, also.  That would frequently be the cleanest way to do 
something.  I understand that this would be essentially implementing 
inheritance for structs, and there may be good reasons to not do this. 
But it would regularize the syntax markedly.  It would make it so that 
the main difference between classes and structs is that classes were 
referenced by handles, and structs were value types.

I don't THINK I've drifted far from the original point.  If I have, my 
appologies.  But where possible I feel that syntax should be made more 
regular.  And this includes being able to test classes, structs, and 
built-in types in templates using the same constructions.  Like opAdd or 
opCmp.  One often doesn't care what kind of thing one is checking, but 
only what features it possesses.  So there should be easy ways to check 
for the possession of those features.

I note that I'm not making a clear distinction between types and 
instances of types, but in D every instance should be an instance of 
some particular type.  I didn't explicitly mention expressions, but the 
definitions of delegates and pointers to functions involve 
expressions...so I'm not exactly certain where the boundary lies.

More on expressions:  if one allows type variables, and testing of type 
variables for features, then it becomes reasonable to allow expressions 
that combine those type variables (and probably type literals).  OTOH, 
even if those type expressions exist, it seems unlikely that the normal 
operations would be the desired ones.  One would be more likely to want 
expressions of the form "if v implements method m and has feature f, 
then ...".  I think this can probably already be done with static if and 
  traits, though I'm not sure if traits are available at compile time.

But HOW COMPLICATED DO YOU WANT TEMPLATE SPECIFICATION TO BE???

OTOH, most of the changes that I want are along the lines of 
regularizing syntax.  And I realize that they may be either too 
difficult or too costly in ways that aren't readily apparent to me. 
Like allowing structures to support inheritance, and having the 
overloaded operator names be accessible for the built-in types.  (And I 
haven't checked that yet.)