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
