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.
