QtD is suspended

[Andrei Alexandrescu]

On 9/16/10 14:37 CDT, Max Samukha wrote:
> On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote:
>> On 9/16/10 9:22 CDT, Max Samukha wrote:
>>> After a good amount of hesitation, we have decided to put the QtD
>>> project on hold. QtD has a potential to become a complete and effective
>>> development platform for D but it is not going to happen soon (unless
>>> people with harder hearts take it over). We have spent half of the day
>>> hunting yet another dmd bug-o-feature and that is the last straw.
>>>
>>> We offer our apologies to people who put their hope upon the project.
>>> Please come back in a year or two when the language has a stable
>>> compiler with the features fully specified, implemented and debugged.
>>
>> Hi Max,
>>
>> Sorry to hear that. Was this an issue of many small annoyances or a few
>> big ones?
>>
>> Thanks,
>>
>> Andrei
>
> Hi Andrei,
>
> Both, I guess.

Thanks for replying. This is very helpful. I'll make some points below, 
definitely not as an attempt to revisit the decision you've already made.

> The recent big one is the unspecified behavior of
> postblit on const/immutable structs and overloading by rvalue/lvalue.
> Specifically, we were bending the generator into generating Qt value
> types as structs and hit two problems:
>
> 1. The generated __cpctor (which does the blit and calls the postblit)
> is always non-const and takes a non-const reference to the original.
> That means copy-construction of const objects is impossible without casts.
>
> To proceed, we had to hack the compiler so that __cpctor took a const
> original reference and was called on a mutable target reference. That
> seemed to work but left us in uncertainty: how it actually should and
> will work?

Walter and I discussed a fair amount about copying objects with 
different qualifiers. The syntax we discussed was

this(this) const { ... }

which would be called after you copy a const or non-const object into a 
const object. Certain special typechecking applies inside that 
constructor, but nothing really difficult; it does entail a fair amount 
of work in the front end, which Walter hasn't find the time to put in.

On a funny note, we figured that for a number of reasons it would help 
to allow C++-style constructors that offer access to the source; it just 
turns out some idioms need to modify the source as well as the destination.

One obvious example is the built-in hashtable that is not shared 
properly when it's null. Making the copy constructor spring the 
hashtable to life would make it more uniform in behavior.

The situation is a bit ironic - we worked on improving upon C++ 
constructors but it turns out something similar is still needed in 
certain situations.

Anyway, regardless of whether C++-style constructors will be supported 
(as an alternative to postblit), the issue you mention is serious. But 
by and large I think the matter could gave have be settled in a 
different manner: by not catering for const in the first release. D has 
a lot to offer besides const, and its const subsystem is a good bit more 
restrictive than e.g. C++'s, mainly to help with concurrency. So until 
the typical D idioms for using const become established, it's not a 
crime to have QtD work without const. I wouldn't go back from a Lexus to 
a Yugo because the Lexus doesn't have a butt warmer :o).

> 2. A bug in the compiler doesn't allow us to overload struct parameters
> by ref-ness. So we had to generate by-value parameters where Qt has them
> by reference.
>
> And today we've encountered two other bugs in sequence. One was about
> the impossibility to access a template instance member from within a
> struct nested in another struct and the second didn't give any line/file
> information.
>
> We could probably work around or ignore all these problems but I think
> it is starting to take more time and nerve than we can afford.

I understand. Let me ask you this - if your bugs had #1 priority, would 
that have helped? I mean, is the slow response time to bug submissions a 
large annoyance factor?


Thanks,

Andrei