stability

[Jarrett Billingsley]

> "Janice Caron" wrote in message
> news:mailman.79.1203955731.2351.digitalmars-d at puremagic.com...
>> On 25/02/2008, Jarrett Billingsley wrote:
>>
>> 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.
>
>

Mr. Denis apparently didn't find his reply worthy of appearing on the 
newsgroups, but I found it relevant nonetheless.

-----------------
Koroskin Denis <2korden at gmail.com> wrote:
You know the feature is incomplete, so just don't use the feature. Why
bother yourself and others?!
-----------------

This is called feedback.  Walter implements something, we tell him whether 
or not we like it.  It's how the language gets better.  Walter *can* make 
mistakes, and when he does, it's generally accepted that people point them 
out and he do something about them.