stability

[Jarrett Billingsley]

"Janice Caron" <caron800 at googlemail.com> wrote in message 
news:mailman.79.1203955731.2351.digitalmars-d at puremagic.com...
> On 25/02/2008, Jarrett Billingsley <kb3ctd2 at yahoo.com> wrote:
>> If the spec _did_ say the same thing as the compiler, I'd at least know 
>> that
>>  the compiler was behaving correctly, and wouldn't be asking Walter to
>>  backport this change to D1.
>
> I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable
> has a spec, since it is stable apart from bug fixes.

I don't use D2.  I haven't really looked at it and I don't even have it 
installed.  The only things I know about D2 are what's written in the 
changelog.  I'm talking about the D1 compiler and D1's spec here.

Secondly, I couldn't possibly be confusing the two specs since *gasp* both 
specs say the same thing about tupleof.  Which is to say, not a whole hell 
of a lot.

> But D2 is constantly evolving, with breaking changes happening every
> few releases. This evolution is the result of experience and feedback.
> D2 /cannot/ have a spec, until some day in the future when it becomes
> stable. Whether or not the D2 compiler is behaving "correctly" rather
> depends on what "correctly" will eventually be, and that's not fixed
> yet. It would therefore make no sense to backport D2 changes to D1
> based on some assumption of spec-compliance, when D2 changes might not
> even be permanent.

IMO something doesn't have to be *finalized* to have a spec.  See C++0x. 
For that matter you can *start* with a specification and build a program 
that follows it.  In fact, that's kind of how I imagined it *should* be 
done..

Let me explain exactly what I'm talking about.  Right now we're talking 
about D1 and D1 only.  This is what the D1 spec says about .tupleof.  Under 
structs/unions, in the "struct properties" table, it says:

.tupleof: Gets type tuple of fields

So there are two things you'll notice.  One, apparently the compiler does 
not implement the spec here, since in the compiler, .tupleof gets you a 
tuple of the fields themselves, and not their types.  typeof(S.tupleof) will 
get you a type tuple of the fields.  Is the compiler wrong or is the spec 
wrong?  Fortunately, because we have both, we can see that there is a 
discrepancy and raise a red flag (aka an RFC, which I will go and do right 
after this).

Two, _this is all it says about tupleof_.  It says absolutely _nothing_ 
about how .tupleof interacts with protection attributes, how it interacts 
with nested anonymous structs and unions, _anything_ really.  It's five 
words.  It's ill-specified.  So in the case where the compiler gives an 
error upon using .tupleof on a struct with private fields, _is the compiler 
acting correctly_?  There's no spec, so there's no discrepancy; instead the 
compiler is AWOL, and I guess it can do anything it wants because the corner 
cases are unspecified.  This is where compiler-dependent stuff crops up and 
it's nothing but headaches.  This instance is a call for a better-defined 
spec.  Even if it's changed to say that it's illegal (and I'd rather it 
wouldn't be), _I don't care_, I want it to say which it is so that I know 
that when I write my code, I know that every compiler I compile it with will 
do the same thing and give me the same errors (or lack thereof).

Long story short: the D1 spec says nothing about tupleof so it could really 
go either way (either keep it the way it is or backport the *present* D2 
way).  There is no harm in backporting, it's a non-breaking change, so I 
don't see why it couldn't be done.