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