www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template Prerequisite proposal

reply davidl <davidl 126.com> writes:
This proposal would break current template legacy code.

import std.stdio;
template k(T)
{
     void func(T t)
     in
     {
         static assert(is(T = int));		// prerequisite
     }
     body
     {
         writefln(t);		// we should constrain the use of type T, because  
it's checked as prerequisite with is(T = int)
				// so we can get it a little bit further.
         T v;
         t~=v;			// this template code should fail at compile time , and  
don't even need to instantiate this template
                                 // because we can't expect a type of is(T  
= int) can have any operator of ~ in this case
     }
}
void main()
{
     mixin k!(int);
}

This suggests another template writing style.


Last proposal actually already works in DMD

I want a little bit further:

class (T)
{
    static invariant
    {
       // we can do some concept check here
    }
    void func(T t)
    {
       T v;
       v = v + t;       // we didn't have the opAdd check in static  
invariant, in my proposal , this code should be rejected.
    }
}

With the prerequisite checking in static invariant, we can apply  
restrictions in "static invariant" to the template code of using type T.



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Sep 17 2007
next sibling parent DavidL <davidl 126.com> writes:
davidl Wrote:


 
 This proposal would break current template legacy code.
 


Template writers can now throw me stones , and hate me  :D 
Or rather write me a hate mail ;D
Sep 17 2007
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to davidl,


 class (T)
 {
 static invariant
 {
 // we can do some concept check here
 }
 void func(T t)
 {
 T v;
 v = v + t;       // we didn't have the opAdd check in static
 invariant, in my proposal , this code should be rejected.
 }
 }


you can thrown static asserts into a class like this:

class Foo(Stone)
{
  static assert(is(Stone : davidl)); // stone must be cast to davidl at some 
time ;-)
}

what I would like to see is a way for a template to have an explicit
specialization 
for a class of things (arrays for instance) and then inside the template 
be able to cause the specialization to fail in favor of another version of 
the template (the general form) The proposed static invariant would do well 
for this.
Sep 17 2007
prev sibling parent reply DavidL <davidl 126.com> writes:
 
 Last proposal actually already works in DMD
 
 I want a little bit further:
 
 class (T)
 {
     static invariant
     {
        // we can do some concept check here
     }
     void func(T t)
     {
        T v;
        v = v + t;       // we didn't have the opAdd check in static  
 invariant, in my proposal , this code should be rejected.
     }
 }


robert gave me a better example for class:

template LionAssertions()   // prerequisite template
{
    static assert(Lion.foodChainPosition == FoodChain.max);
    static assert(Mufasa > Aslan, "this program contains evil lies");
}

class Lion : AwesomenessIncarnate
{
    mixin LionAssertions!()
}

For common case:

template k(T)
{
	static assert(T.max==int.max);
}

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.
Sep 17 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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?
Sep 17 2007
parent DavidL <davidl 126.com> writes:
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.
Sep 18 2007