Template issues in D

[Bill Baxter]

Burton Radons wrote:
> Bill Baxter Wrote:
> 
>> ------------------------
>> 2) Lack of Overloading:
>>
>> The second big category of headaches comes from lack of overloading.
>>
>> 2a) Functions and templates.
>> You can't have a function and a template with the same name.  C++ has no 
>> problem with this.  I don't see why D should.  The workaround isn't 
>> terribly onerous, but then again neither should it be a terribly 
>> difficult fix, I suspect.
>>
>> 2b) Templates and templates
>> This is worse.  You can't overload templates with other templates of the 
>> same # of parameters even if the signatures are unambiguious.  This is 
>> where the infamous "dummy=void" hack comes in.
>>
>> 2c) No ADL:
>>
>> Not being able to overload templates across modules kills user 
>> extensibility of templates.  It's a very common pattern in C++ code.  A 
>> generic class in a library uses Traits<T> to get info about a class.  If 
>> you make a new MyT, you can integrate your class into the lib by 
>> providing your own specialization of Traits!(MyT).  In D to get this you 
>> have to modify the original module where Traits! is defined.
>>
>> It's like saying that to extend a class from a library you should edit 
>> the library's source code and add a member to the class there.  It is 
>> the antithesis of modular code.
>>
>> I hope this will be fixed in D2 by the overload sets stuff, but I 
>> consider D1 broken for lack of this.
> 
> I'm not so sure I want the language to act differently just for templates. 

If you're referring to the request to put it in D1, I can understand 
your reluctance.  Personally I'd like to see *all* backwards-compatible 
changes ported to D1, but that's just me.

If you're referring to D2, then I'm not really talking about things 
acting differently.  At least not different from the "overload sets" 
discussed in WalterAndrei.pdf.  The idea presented there was that it 
would be legal to import foo(char[] x) and foo(float[] x) from different 
modules into the same namespace.  The plan was to make that ok as long 
as there's no potential for ambiguity.  So really I'm just asking for 
that to work with templates too.  It only seems iffy to me because basic 
template overloading has so many issues it seems unlikely that template 
overload sets are going to work without somebody pushing for it.

 > What I would like is for specialisations to be predicatable.
> That would not only give us the power of extensible templates, but it would allow new features as well. So I would use:
> 	
> 	// Or whatever you'd use to get the values of an array.
> 	T add_arrays (T = is_array! (T) && is_numeric! (array_values! (T))) (T a, T b)
> 	{
> 	}
> 
> I would be very happy with that, and the compiler could specially understand that so might fail it with "array_add cannot be used with foo because it failed the is_array predicate." We could be doing very different things with templates though so that might not work for you.

I don't see how that solves the problem I'm talking about.  It would be 
nice to have what you're asking for too, but it doesn't solve the 
template extensibility issue.   Using your example, the issue is if I 
have an array class I took from some other library and want to use it 
with yours, how do I get your array_values!(T) template to accept this 
ThirdPartyArray type?  I know how to get the values out  and I can 
easily write the specialization that would do it:

     vals array_value!(T : ThirdPartyArray) { ... }

But currently the only way for that to work is if I put that 
specialization in the *same text file* as your function, which kills the 
whole concept of having a library.

--bb