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