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. 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'll read about your 3rd thing when I have time.

Oh and I should add that I whole-heartedly support fixing templating issues. The trouble is that templating in D is kind of like templating in C++ - you need to know far too much about the way the language works because if you treat it in a way it doesn't expect, it'll reject your code with some very foolish errors. The difference and the extra frustration is that when C++ rejects code it's because the language is stupid, but when D rejects code it's because the compiler isn't robust. So knowing the language isn't even enough. This is the kind of basic feature that the compiler needs to be handling correctly.

If const is what's taking up Walter's time then, well, that's just more proof that const is an evil, worthless concept in addition to it providing no useful information to the compiler, forcing casts everywhere (the most dangerous operation made mandatory, great!), making the compiler more complex, making it very difficult to port D code up (and yes, I tried it, and stopped after two hours), infecting code which doesn't want to deal with this nonsense, ...

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

Burton Radons wrote:

> I'm not so sure I want the language to act differently just for templates. 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."

Maybe you want something like type classes (http://en.wikipedia.org/wiki/Type_class). The code above could look something like (another more D style alternative is c++0x concepts, I think, but I can't remember their syntax):

  add_arrays:: [T] [T] -> [T] | Numeric T
  add_arrays a b = ...

I'm not sure if the current syntax can be elegantly abused to accept these. A dedicated syntax would be much easier to read and would work in cases where you want bounded polymorphism with predicates.

== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> Burton Radons wrote:
> > 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.

It seems to me that Walter is avoiding fixing bugs for D1. That's a bad sign in my opinion.

For example, one of the bugs that you mentioned - http://d.puremagic.com/issues/show_bug.cgi?id=493 - was apparently a pre-D1 bug (0.173). Instead of telling us that the spec for D1 doesn't allow this, he tells us that DMD 2.011 was enhanced to do this. Is he thinking: "I'm careful to not call it a bug so that I won't have to fix D1"?

If D1 is being abandoned and D2 isn't ready for the prime time, where can we can go to find a stable bug-free compiler?

And by the way until a big project (such as Tango or DFL or DWT) is converted to D2, I'm suspicious that the new const stuff will be more trouble than it's worth. What's the biggest project that has been converted to D2?

I know that Walter has converted Phobos and MicroEmacs to D2, but I doubt that either of those projects are big enough to really see how the new const stuff works.


By the way, this thread has converged with a separate thread...

From "stable != abandoned [was: My Kingdom For ...]", http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=66544

<quote>
I agree. D1.0 looks more "abandoned" than "stable". A language should keep moving
even when it's stable, as long as the changes are backward
compatibles. That mean that a new syntax that was previosly forbiden or new
additions to the standard library could be done without affecting stability.
</quote>