Template Prerequisite proposal

DavidL davidl at 126.com
Tue Sep 18 01:44:27 PDT 2007


Robert Fraser Wrote:

> DavidL Wrote:
> > For common case:
> > 
> > template k(T)
> > {
> > 	static assert(T.max==int.max);
> > }
> 
> To test types, you could just use the "is" expression (unless there was a special reason you were comparing to int.max?):
> 
> static assert(is(T == int)); // Compilation will fail if T is not int
> static assert(is(U : Lion)); // Compilation will fail if U is not implicitly castable to Lion
> 
> > 
> > template a(T)
> > {
> > 	void func(T t)
> > 	in
> > 	{
> > 		mixin k!(T);
> > 	}
> > 	body
> > 	{
> > 	}
> > }
> > 
> > mixin a!(int);
> > 
> > 
> > so there's a unified way of mixin template for prerequisite checking.
> > 
> > I hope if there's any way of restrict template writer write code which only uses things which are checked in the prerequisite checking.
> 
> I'm not sure exactly what you mean. Example?

The idea is current prerequisite checking is nice, but we are not able to restrict template writers only uses stuff which are checked in the prerequisite part. 

Making the requisite part mandatory would bring us clean template. thus no compilation error inside a well written template when we instantiate it or call some func of it.

Also IDE can take advantage of providing template writer code-completion.
consider a class type prerequisite check: 
static assert(__traits(hasMember, T, "m"));
then code completion when you go to a point:
T myobject;
myobject.  (right after the dot, IDE can show you a candidate of member "m")

the prerequisite checking is actually internally a process of building a type. 
If we can have the power to build a type and make the specialization to take advantage of user defined type, then it's most instinct.

Consider building a type of class,
psuedo code:
typedef   class  mytype
{
   int m;
   int func();
}; 

then if we have 
class myclass
{
   int n,m; // we matches one prerequisite
   int func();  // we reaches another prerequiste
   int blah();
}

then when we do a template specialization:
template mytemp(k:mytype)
{
}
mixin mytemp!(myclass);  // compiler checks if myclass conforms to the type named 'mytype', yet this mixin currently fails.

we might need some concept_map (myclass, mytype); to let compiler internally know myclass conforms to mytype, and do the checking right there.
checking stuff of concept_map could be done by using current meta-programming stuff. While you can't make compiler internally know myclass can implicitly 'cast' to mytype;
umm, till we get implicitlycastto in d2.0 I think the concept_map is totally possible in library land. 

All C++ concept stuff is actually a process of building a virtually type for prerequisite checking from my point of view.





More information about the Digitalmars-d mailing list