Is D 0.163 D 1.0?

Oskar Linde oskar.lindeREM at OVEgmail.com
Fri Jul 28 05:42:44 PDT 2006


Oskar Linde wrote:
> Bruno Medeiros wrote:
>> Oskar Linde wrote:
>>> Dave skrev:
>>>> Don Clugston wrote:
>>>>> Georg Wrede wrote:
>>>>>> John Demme wrote:
>>>>>>> Walter Bright wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I think the title says it all.
>>>>>>>
>>>>>>>
>>>>>>> Has anyone recommended that 0.163 should be labelled RC1?  I 
>>>>>>> think this
>>>>>>> would be fair- hopefully it would focus attention from language 
>>>>>>> changes to
>>>>>>> finding major bugs/flaws and the "Shop's closed- let's clean up 
>>>>>>> and ship
>>>>>>> it" mentality.  It would tell people who are maintaining 
>>>>>>> libraries to
>>>>>>> bother to update them to 0.163 so they will work with 1.0.
>>>>>>
>>>>>> This sounds quite reasonable.
>>>>>
>>>>> I agree. 0.163 seems like a solid feature base to build 1.0 
>>>>> libraries around. But I wonder how long Walter will be able to 
>>>>> restrain himself from adding new features; I think he'd get bored 
>>>>> after a dozen releases containing nothing but bug fixes. <g>
>>>>
>>>> I'm actually hoping that one of the reasons for releasing 1.0 now is 
>>>> because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't 
>>>> good enough, just that it's fun to "play" :))
>>>>
>>>> I'm curious - are there really any "show stopping" type bugs out 
>>>> there for v1.0? By show stopping I mean bugs that completely prevent 
>>>> a given design pattern allowed by the current language spec.
>>>
>>> I'd say the implicit function template instantiation limitations are 
>>> somewhat show stopping:
>>>
>>> 1. IFTI doesn't work for member functions.
>>> 2. Partial specialization doesn't work with IFTI.
>>> 3. Partial template instantiation isn't allowed with IFTI.
>>> 4. More IFTI limitations...
>>>
>>> Walter has acknowledged that number 2 is a bug. I don't know of any 
>>> workaround for number 1. Those are all hampering library development, 
>>> which IMHO would qualify as show stoppers for a 1.0 status.
>>>
>>> Of course, the most important thing is to make clear which 
>>> limitations are meant to remain and which are to be classified as bugs.
>>>
>>> /Oskar
>>
>> What is partial specialization ? And Partial template instantiation? 
>> (does that come from C++?)
> 
> The term "partial specialization" isn't mentioned in the D spec, but its 
> meaning is documented under "Specialization" in 
> http://www.digitalmars.com/d/template.html
> It basically means that you can specialize a template for e.g. all 
> pointers:
> template tmp(T:T*) {...}
> 
> By partial template instantiation (I have no idea if this is the correct 
> term), I mean specializing a template partially explicitly and partially 
> implicitly.  E.g:
> 
> A myCast(A,B)(B x) { return cast(A)x; }
> ...
> myCast!(float)(5);
> 
> No template declaration fully matches myCast!(float). It gets partially 
> instantiated and the remaining template parameter B is automatically 
> deduced.

An interesting question is if there really is a huge need for this in D. 
D's templates are already more powerful than C++, and the above example 
can be written:

template myCast(A) {
	A myCast(B)(B x) {
		return cast(A)x;	
	}
}

(C++ will get this too, one day)

The difference to C++ is (in D syntax), given:

A func(A,B)(B x) { return 1; }
A func(A)(double x) { return 0; }

Then:

In C++, func!(int)(5) would return 1, whereas in D, without partial 
template instantiation, it would return 0.

C++ may make this more complicated than necessary. IMHO, C++ has too 
many different ways of achieving polymorphism and they all work together 
making the overload resolution overly complicated.

/Oskar



More information about the Digitalmars-d mailing list