• bearophile <bearophileHUGS lycos.com> Jul 09 2008
• "Koroskin Denis" <2korden gmail.com> Jul 09 2008
• Walter Bright <newshound1 digitalmars.com> Jul 09 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 09 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Jul 09 2008
• Sean Kelly <sean invisibleduck.org> Jul 09 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Jul 09 2008
• Sean Kelly <sean invisibleduck.org> Jul 09 2008

bearophile <bearophileHUGS lycos.com> writes:

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

"Koroskin Denis" <2korden gmail.com> writes:

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.

Walter Bright <newshound1 digitalmars.com> writes:

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.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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 

Sean Kelly <sean invisibleduck.org> writes:

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.


 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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


 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 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 

Sean Kelly <sean invisibleduck.org> writes:

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.


 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 to have bugs that were reported when D2 was not even a twinkle in your 
 eye not being fixed until D2.


 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.



     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