Lars Ivar Igesund:
> There is another one triggered by the Tango unittests: tango/core/Variant.d(361): Error: functions cannot return static array char[3u]

That's a bug in older versions of DMD, I think.

Bye,
bearophile

On Wed, 09 Jul 2008 15:12:34 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Lars Ivar Igesund:
>> There is another one triggered by the Tango unittests:
>> tango/core/Variant.d(361): Error: functions cannot return static array
>> char[3u]
>
> That's a bug in older versions of DMD, I think.
>
> Bye,
> bearophile

Maybe, but so-called stable version should provide bug-compatibility as well :)
But then, there are people who want to have certain breaking bugs fixed. Can't please everyone.

Koroskin Denis wrote:
> Maybe, but so-called stable version should provide bug-compatibility as well :)
> But then, there are people who want to have certain breaking bugs fixed. Can't please everyone.

And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g52v0a$13hh$5@digitalmars.com...
> Koroskin Denis wrote:
>> Maybe, but so-called stable version should provide bug-compatibility as
>> well :)
>> But then, there are people who want to have certain breaking bugs fixed.
>> Can't please everyone.
>
> And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.

I agree with your decision not to fix 288 in D1, but it *is* frustrating to have bugs that were reported when D2 was not even a twinkle in your eye not being fixed until D2.

"Jarrett Billingsley" wrote
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g52v0a$13hh$5@digitalmars.com...
>> Koroskin Denis wrote:
>>> Maybe, but so-called stable version should provide bug-compatibility as
>>> well :)
>>> But then, there are people who want to have certain breaking bugs fixed.
>>> Can't please everyone.
>>
>> And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.
>
> I agree with your decision not to fix 288 in D1, but it *is* frustrating to have bugs that were reported when D2 was not even a twinkle in your eye not being fixed until D2.

I have to say I wish D1 did have opEquals returning bool, but I'm on Walter's side on not changing it now.  This is not a bug, but a design change.  The original version (returning int) worked as designed, there was nothing 'broken' about it.

-Steve

Steven Schveighoffer wrote:
> "Jarrett Billingsley" wrote
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g52v0a$13hh$5@digitalmars.com...
>>> Koroskin Denis wrote:
>>>> Maybe, but so-called stable version should provide bug-compatibility as well :)
>>>> But then, there are people who want to have certain breaking bugs fixed. Can't please everyone.
>>> And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.
>> I agree with your decision not to fix 288 in D1, but it *is* frustrating to have bugs that were reported when D2 was not even a twinkle in your eye not being fixed until D2.
> 
> I have to say I wish D1 did have opEquals returning bool, but I'm on Walter's side on not changing it now.  This is not a bug, but a design change.  The original version (returning int) worked as designed, there was nothing 'broken' about it.

I'd consider this broken about it:

    bool isEqual( Object x, Object y )
    {
        return x == y; // fails
    }

You have to cast the result to bool.


Sean

"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> "Jarrett Billingsley" wrote
>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g52v0a$13hh$5@digitalmars.com...
>>>> Koroskin Denis wrote:
>>>>> Maybe, but so-called stable version should provide bug-compatibility
>>>>> as well :)
>>>>> But then, there are people who want to have certain breaking bugs
>>>>> fixed. Can't please everyone.
>>>> And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.
>>> I agree with your decision not to fix 288 in D1, but it *is* frustrating to have bugs that were reported when D2 was not even a twinkle in your eye not being fixed until D2.
>>
>> I have to say I wish D1 did have opEquals returning bool, but I'm on Walter's side on not changing it now.  This is not a bug, but a design change.  The original version (returning int) worked as designed, there was nothing 'broken' about it.
>
> I'd consider this broken about it:
>
>     bool isEqual( Object x, Object y )
>     {
>         return x == y; // fails
>     }
>
> You have to cast the result to bool.

Again, behaves as designed :)  The compiler and the runtime both behave exactly as the spec dictates.  Designs decisions can suck, and be inconsistent with the philosophy of the project (as in this case), but that doesn't make them bugs.  They are still arbitrary decisions, with no clear cut 'right' or 'wrong'.

Take Tango's 'anti import' design philosophy.  It was made because a goal of Tango is to not bloat code, and the compiler happens not to trim out unused coded from modules.  I disagree with that decision, as I think D applications are bloated inherently anyways, and once dynamic libraries are natively supported, this becomes a moot issue.  But that doesn't mean I consider the design decision to be a 'bug', it just is something I disagree with, but live with.

-Steve

Steven Schveighoffer wrote:
> "Sean Kelly" wrote
>> Steven Schveighoffer wrote:
>>> "Jarrett Billingsley" wrote
>>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g52v0a$13hh$5@digitalmars.com...
>>>>> Koroskin Denis wrote:
>>>>>> Maybe, but so-called stable version should provide bug-compatibility as well :)
>>>>>> But then, there are people who want to have certain breaking bugs fixed. Can't please everyone.
>>>>> And we also have #288 where Sean wants a breaking language change put into 1.0. I cannot justify that, but fixing bugs where invalid code was accepted is justifiable.
>>>> I agree with your decision not to fix 288 in D1, but it *is* frustrating to have bugs that were reported when D2 was not even a twinkle in your eye not being fixed until D2.
>>> I have to say I wish D1 did have opEquals returning bool, but I'm on Walter's side on not changing it now.  This is not a bug, but a design change.  The original version (returning int) worked as designed, there was nothing 'broken' about it.
>> I'd consider this broken about it:
>>
>>     bool isEqual( Object x, Object y )
>>     {
>>         return x == y; // fails
>>     }
>>
>> You have to cast the result to bool.
> 
> Again, behaves as designed :)  The compiler and the runtime both behave exactly as the spec dictates.  Designs decisions can suck, and be inconsistent with the philosophy of the project (as in this case), but that doesn't make them bugs.  They are still arbitrary decisions, with no clear cut 'right' or 'wrong'.

Okay, fair enough :-)  I'd still consider this to be a flaw in the spec since the result of a logical operation should always be boolean, but that's obviously just my opinion.


Sean