Is D 0.163 D 1.0?

Oskar Linde oskar.lindeREM at OVEgmail.com
Fri Jul 28 02:42:23 PDT 2006


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.

/Oskar



More information about the Digitalmars-d mailing list