QtD is suspended

[Max Samukha]

On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote:
>
> 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.

Nice to hear that the problem is being worked on. What kind of 
typechecking will be performed in const/immutable postblit?

>
> 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.

Funny. We seem to be in the opposite situation. We originally thought 
that postblit won't be enough for QtD but it looks like copying most (or 
all, not sure) value types in Qt do not need access to the source object.

>
> 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.

The thing is that D's const looked well suited for our purpose. Postblit 
and const were discussed in TDPL so we concluded that their design and 
implementation were more or less complete and harmonized. We took the 
effort to change the generator to properly generate const qualifiers and 
only after that discovered the postblit issues.

> I wouldn't go back from a Lexus to
> a Yugo because the Lexus doesn't have a butt warmer :o).

:) The Lexus doesn't start and has an obscenity scratched on its hood. A 
butt warmer would double its resale price.

>
>> 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?

Definitely. The notorious one 
(http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD 
development on Windows, drove a couple of good users away from D and 
became a powerful FUD generator, was submitted 4 years ago.

>
>
> Thanks,
>
> Andrei

I think one of the big factors causing annoyances is miscommunication. 
While you have immediate access to Walter, most of us have to settle for 
this NG and #d IRC channel (the latter has become a source of nothing 
but discouragement).

We carefully follow discussions (at least we try to) in the mail-lists 
and NG but often do not know what is the final decision on a problem 
having been discussed.

One example is the semantics of clear() and scoped(). As I understood 
from one of your posts, you agree that resurrecting the destroyed object 
by calling its default constructor is objectionable. However, no further 
action followed. So we are at a loss whether you have a better solution, 
are still thinking about one, don't have time to change the 
implementation or don't want to change the thing because it is engraved 
in TDPL. The same applies to 'scoped' moving the object.

Another example is half-implemented 'inout'. Is a correct implementation 
fundamentally impossible or Walter haven't had time for it?

Such unterminated discussions tend to stack up in our minds creating a 
possibly very exaggerated image of instability.