"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g534cj$1jav$2@digitalmars.com...
> Sean Kelly wrote:
>> But it's a breaking change that people asked for two years ago, before D 2.0 was announced.  Besides, breaking changes are made to D 1.0 all the time anyway, as evidenced by the fact that all of the past 4 DMD 1.x releases have broken Tango in one way or another.  I grant that, as a silent breaking change this is somewhat of a bigger deal, but I suspect that our users would gladly change their code to have this in 1.0.
>
> Creating a spec-changing breaking change for D 1.0 is not its charter, which is to be a stable release of D that is not getting breaking spec changes.

Uh, .init?

New bug introduced in 2.016  (2.015, 2.013 are ok)

$ ../dmd-v2.016/bin/dmd -c staticif.d
staticif.d(27): Error: no property 'f' for type 'staticif.AA'
staticif.d(27): Error: function expected before (), not 1 of type int
staticif.d(28): Error: no property 'f' for type 'staticif.BB'
staticif.d(28): Error: function expected before (), not 1 of type int

$ cat staticif.d

class A {
}

class B {
}

template T(X) {
static if (is(typeof(X) : A) ||
           is(typeof(X) : B) ) {
void f() {
}
}

}

class AA {
  mixin T!(A);
}

class BB {
  mixin T!(B);
}

int main() {
  AA a = new AA();
  BB b = new BB();
  a.f();
  b.f();

  return 0;
}

user Wrote:
> New bug introduced in 2.016  (2.015, 2.013 are ok)
> template T(X) {
> static if (is(typeof(X) : A) ||
>            is(typeof(X) : B) ) {

The situation applies to 1.031 too. Try changing that to:

    static if (is(X : A) || is(X : B) ) {

Bye,
bearophile

Sean Kelly wrote:
>     T fn(T)( T val ) { return val; }
> 
> Shouldn't the above be valid for all types?

Except for static arrays, it seems.

void fn(T)( ref T val ) {}

also excludes static arrays.

Christian

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> Mostly bug fixing.
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.032.zip
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.016.zip
> 
> I don't suppose there's any chance that bugzilla 288 could be fixed
> in 1.0 as well?  I know it's a breaking change from a code perspective,
> but it was clearly considered a bug in 1.0, and it makes maintaining
> cross-compatible code between 1.0 and 2.0 difficult at best.

This one seems easier than many other things to make cross-version compatible.   Can't you pretty much just do

version(D_Version2) {
   alias bool OpEqBool;
} else {
   alias int OpEqBool;
}

And use int inside opEquals itself, but throw in a cast to bool on the return value for D2.  Seems like that would work.

--bb

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> I agree that there is no particular need to upgrade, although new DMD
>> releases tend to have bugfixes that are important to Tango users.
>> Furthermore, D users expect any D 1.0 library to work with the next DMD
>> 1.0xx compiler release, it is a stable branch after all. When this does not
>> happen, i.e the compiler has a breaking change, there is some furious work
>> at our end to figure out what the heck is wrong, with potentially quite a
>> few requests and pings from the users (I speak from experience).
> 
> I apologize for that.

Maybe you can demonstrate the sincerity of your apology by getting a 1.032r1 version out the door in the next few days, which does nothing but fix these regressions.

The problem as I see it is that you keep changing too many things.  If after reports of regressions came in you just regularly cranked out a new release that fixed *only* those, then everybody could be satisfied I think.

In effect it would be like a pre-release system, except _everybody_ would get the same chance to try the pre-releases, and in the event that no regressions are found in the release, there's no need to re-release.

Anyway I think it's clear that /something/ needs to be done if you're really serious about making D1 a stable branch.  And this seems like it would be the least painful option for you.

--bb

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> BCS wrote:
>>> If you could test dmd with tango from a single shell script (runs SVN up; some tests; etc) would you add that to the pre release tests?
>> The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.
> 
> No, Tango devs will be debugging it.

Not if I'm running it as part of the release cycle. Having 100K of source code that is unknown to me that dies somewhere in it will be a huge and impractical burden. What would take me many hours would take the person who wrote the code a few minutes.

The people who know that code need to be the ones to check it out, because they can efficiently isolate it. Then, I can add the small test case to my test suite and it will stay fixed. Over time, this aggregate of small test cases is much more effective at keeping the quality stable than sheer masses of opaque code.

> Hell, let them do the work with a pre-release compiler.  I'll volunteer to do it.  If they determine it is a DMD bug, they give you a minimal case, and then you go back and fix it, or you determine that it can't be fixed for this release (with appropriate bugzilla entry logged).

That is a practical way.

> But without access to the compiler pre-release, there is not much the Tango guys can do except say "another stable release that is broken"

I agree.

> And all this is moot if we can build dmd from source :)  It would be nice to be able to help...

I know.

Walter Bright wrote:
> Sean Kelly wrote:
>> So if I do this:
>>
>>     int[3] x;
>>     fn( x );
>>
>> I should expect to get a compile error?
> 
> If fn returns a static array, yes.

And given my sample implementation of fn:

    T fn(T)( T val ) { return val; }

Then I assume the answer is yes?  If so, then I'm not sure how to interpret your "yes, but..." response to my prior post.  Clearly this function isn't valid for all types if T can't be a static array type.


Sean

Walter Bright wrote:
> Sean Kelly wrote:
>> But it's a breaking change that people asked for two years ago, before D 2.0 was announced.  Besides, breaking changes are made to D 1.0 all the time anyway, as evidenced by the fact that all of the past 4 DMD 1.x releases have broken Tango in one way or another.  I grant that, as a silent breaking change this is somewhat of a bigger deal, but I suspect that our users would gladly change their code to have this in 1.0.
> 
> Creating a spec-changing breaking change for D 1.0 is not its charter, which is to be a stable release of D that is not getting breaking spec changes.

So basically, even if bug reports were opened against D 1.0 before D 1.0 was finalized, if fixing them involves a breaking change then we'll never see them in D 1.0.  Is this correct?

On a related note, there were some other issues fixed in D 2.0 but not 1.0 that I don't believe were spec-related and which were also reported against 1.0 before 2.0 was announced.  I can't recall what they were offhand... IFTI issues perhaps?  What was the reasoning behind this decision?


Sean

Bill Baxter wrote:
> Sean Kelly wrote:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> Mostly bug fixing.
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.032.zip
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.016.zip
>>
>> I don't suppose there's any chance that bugzilla 288 could be fixed
>> in 1.0 as well?  I know it's a breaking change from a code perspective,
>> but it was clearly considered a bug in 1.0, and it makes maintaining
>> cross-compatible code between 1.0 and 2.0 difficult at best.
> 
> This one seems easier than many other things to make cross-version compatible.   Can't you pretty much just do
> 
> version(D_Version2) {
>    alias bool OpEqBool;
> } else {
>    alias int OpEqBool;
> }
> 
> And use int inside opEquals itself, but throw in a cast to bool on the return value for D2.  Seems like that would work.

So long as all users of Tango do the same thing.  I'm fine with doing this sort of thing behind the scenes in Tango, but not if it imposes similar requirements on our users.


Sean