Stroustrup's talk on C++0x

[Oskar Linde]

Reiner Pope wrote:
> Walter Bright wrote:
>> Reiner Pope wrote:
>>>  1. Will specialisation be "fixed" to work with IFTI?
>>
>> You can simply specialize the parameter to the function.
> 
> I'm not sure what you mean. 

Neither am I...

[snip]

> Sure. But the following doesn't work:
> 
> void Foo(T)(T t) { ... }
> void Foo(T)(T* t) { /* different implementation for this specialisation 
>  */ }
> ...
> int x;
> Foo(x);
> Foo(&x); // ambiguous
> 
> and using template parameter specialisation, IFTI breaks.

This is the workaround I've been using:

void Foo_(T: T*)(T* a) { writefln("ptr"); }
void Foo_(T)(T a) { writefln("non-ptr"); }

// dispatcher
void Foo(T)(T x) { Foo_!(T)(x); }

void main() {
	int x;
	Foo(x);
	Foo(&x);
}

>>>  2. Will there be a way to support user-defined specialisations, for 
>>> instance once which don't depend on the inheritance hierarchy?
>>
>> I don't know what that means - interfaces are already user-defined.
> 
> They are, but they only allow you to stipulate requirements on the types 
> place in the inheritance hierarchy. Two things that inheritance doesn't 
> cover is structural conformance, and complicated predicates.
> 
> Structural conformance is clearly important simply because templates 
> make it possible and it avoids the overheads of inheriting from an 
> interface. This is what C++ Concepts have on D interface specialisation.
> 
> As to complicated predicates, I refer to the common idiom in D templates 
> which looks like the following:
> 
> template Foo(T)
> {
>     static assert(SomeComplicatedRequirement!(T),
>         "T doesn't meet condition");
>     ... // implementation
> 
> }
> 
> (SomeComplicatedRequirement is something inexpressible with the 
> inheritance system; something like "a static array with a size that is a 
> multiple of 1KB")
> 
> Some people have suggested (Don Clugston, from memory) that failing the 
> static assert should cause the compiler to try another template 
> overload. I thought this would be easier if you allowed custom 
> specialisations on templates. This would allow the above idiom to turn 
> into something like
> 
> template Foo(T :: SomeComplicatedRequirement)
> {
>     ...
> }


> The user-defined specialisation would be an alias which must define two 
> templates which can answer the two questions:
> 
>  - does a given type meet the requirements of this specialisation?
>  - is this specialisation a superset or subset of this other 
> specialisation, or can't you tell? (giving the partial ordering rules)
> 
> This allows user-defined predicates to fit in neatly with partial 
> ordering of templates.

My suggestion has been the following:

template Foo(T : <compile time expression yielding boolean value>), 
where the expression may depend on T. E.g:

template Foo(T: RandomIndexableContainer!(T)) { ... }

template RandomIndexableContainer(T) {
   const RandomIndexableContainer =
	HasMember!(T, "ValueType") &&
	HasMember!(T, "length") &&
	HasMember!(T, "opIndex",int);
}

Even something like this should be possible:

struct RandomIndexableContainerConcept {...}

template Foo(T: Implements!(T, RandomIndexableContainerConcept)) {
}

or something.

This suggestion lacks the partial ordering of specializations, but those 
could be probably imposed on a case by case basis by nesting the conditions.


-- 
Oskar