QtD is suspended

[Andrei Alexandrescu]

On 09/17/2010 09:02 AM, Max Samukha wrote:
> On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote:
> Nice to hear that the problem is being worked on. What kind of
> typechecking will be performed in const/immutable postblit?

The tricky part in that constructor is that you must be able to assign 
the fields, so they are effectively non-const, but you must NOT escape 
outside the constructor as modifiable lvalues. Consider:

int * global;

void foo(ref int x) { global  = &x; }

struct S {
     int a;
     this(this) immutable {
         a = 5;
         foo(a);
     }
}

The program should not compile. If it did, global would be a backdoor 
for modifying an immutable object. Replacing const with immutable seems 
to make things less stringent, but not in reality. The same typechecking 
must be applied to const postblit because const is a subtype of immutable.

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

Yah, it's a relatively rare situation. I enjoy the robustness of 
this(this), but see my most recent post.

> 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 understand. Were it not for that particular issue, it's not impossible 
you would have run into some others. D's immutability subsystem is not 
new, but it's one of the first deployed in a practical language. Just 
like with other features (exceptions, templates, lambdas, AOP...), some 
time is needed for the appropriate idioms to emerge. QtD was the first 
large-scale deployment of const, and it was expected to run into 
practical as well as theoretical matters. We haven't deployed const into 
Phobos yet for the same reason, and there is ongoing discussion on how 
to best go about it.

Bottom line, I have a few thoughts on the matter. First, at this point 
in const's maturity, it's easier to convert a working codebase to using 
const than to design one from scratch for const. This is 
counter-intuitive, but it's dictated by const's immaturity. I'm sure the 
trend will reverse in a couple of years.

(Come to think of this: it took over 15 years for C++'s exceptions to 
achieve any sign of idiomatic usage, and even now very few people know 
e.g. how to transport one exception from a thread to another. Java has 
made obvious-in-hindsight errors in designing its exception subsystem, 
even though it already had a large body of experience with C++ at its 
disposal.)

Second thought is, I am sure the use of D's const, even after it 
matures, will be less pervasive than the use of const in C++. This 
inescapably follows from the fact that D const guarantees more and is 
more restrictive than C++'s const. In C++ I slap const on anything that 
comes in sight: function parameters, stack variables, member 
functions... At the same time, I fully realize that the assurance I get 
in return is quite weak. In D, I afford only a subset of uses of const, 
but the payout is much more powerful.

Third thought is, we did not find the design for immutable and const as 
much as the design found us. What we wanted was a guarantee that you get 
to share immutable data, which we always believed is fundamental. 
Everything else was aftermath.

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

And a tank full of gas would triple it :o).

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

That bug comes often in my chats with Walter. The fact of the matter is 
that that is a difficult bug to find and fix in an assembly program. 
Walter is working slowly on translating the linker into C, which should 
simplify a lot of things. I'll also add that he did fix two comparably 
pernicious linker bugs, one recently.

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

Yah :o). I occasionally lurk there. It's amusing but hardly productive.

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

I understand. At the same time, only this post took me quite a long 
time. Just like you all, most of my time of day is already spoken for. 
Doing my best.

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

Good point. Also, clear() has been a favorite topic on #d because it's 
good evidence of my incompetence.

The intent of clear(obj) is rather simple. It's supposed to put obj in a 
well-defined, destroyable state that does not allocate resources. It's 
the type system's last-ditch effort to preserve safety while at the same 
time releasing all object state.

Currently, clear() works incorrectly for classes, where it invokes the 
default constructor. SVN doesn't assign the blame to me, but the 
decision does originate in discussions I took part in. clear() shouldn't 
call the default constructor of the class because then the class object 
is free to allocate resources once again. What it should do is to blast 
the default initializer for each field in the class. That's a 
well-defined state that doesn't allocate resources - great.

There are two problems with that state. One, the state might fail the 
invariant of the object, but that's expected - once you called clear(), 
you leave an empty shell behind that's unusable unless you reseat 
something into it.

Second, calling the destructor again from that state is problematic 
(because of failing the invariant) and the GC calls the destructor. This 
is also solvable: the GC might memcmp() the state of the object against 
its default state. If comparison comes positive, the destructor is not 
invoked. We need to be careful that doesn't impact collection times.

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

A correct implementation is possible and we have a good understanding of 
what it takes. Walter didn't get around to it yet.

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

I understand. Oddly enough, we only now have such a productive 
discussion, after the destructor has been called :o).


Andrei