February 24, 2014
On 2/24/2014 12:45 AM, Andrew Edwards wrote:
> The final release of DMD 2.065 is now available. [1] contains complete
> descriptions of all changes, enhancements and fixes for this release.

Thank you, everyone, for this release! And a special thanks to Andrew who stepped up to organize and manage the release process.

February 24, 2014
On Mon, 24 Feb 2014 16:09:39 -0500, Meta <jared771@gmail.com> wrote:

> On Monday, 24 February 2014 at 21:00:53 UTC, Steven Schveighoffer wrote:
>> I think the change should go (if it was intentional).
>>
>> IIRC, opCmp was required in D1 and older versions of D2, because hash collisions were stored in a tree instead of a LL.
>>
>> The documentation should be updated too.
>>
>> -Steve
>
> Why *was* there a change to enforce that AA keys have opCmp? It doesn't seem to me like any responses SiegeLord got were satisfactory, i.e., why was this change made, and why was it not in the changelog?

A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident.

But wild guesses don't help fix bugs :)

In doing a search through my email of the dmd-internals mailing list, I don't see opCmp anywhere.

-Steve
February 24, 2014
On Monday, 24 February 2014 at 21:22:12 UTC, Steven Schveighoffer wrote:
> A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident.
>
> But wild guesses don't help fix bugs :)
>
> In doing a search through my email of the dmd-internals mailing list, I don't see opCmp anywhere.
>
> -Steve

Ah, I see. I got the impression that he thought it was a deliberate change, which is why he was so irate. Maybe someone should mention this in the thread.
February 24, 2014
On Mon, 24 Feb 2014 16:23:45 -0500, Meta <jared771@gmail.com> wrote:

> Ah, I see. I got the impression that he thought it was a deliberate change, which is why he was so irate. Maybe someone should mention this in the thread.

I did, but I have a feeling it won't help :)

-Steve
February 24, 2014
On Monday, 24 February 2014 at 18:58:50 UTC, Andrei Alexandrescu wrote:
> On 2/24/14, 4:24 AM, Francesco Cattoglio wrote:
>> On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:
>>
>>> Not really. This pull introduce the virtual keyword. The next step
>>> will afaik force you to write on every method if it is virtual or
>>> final. The step afterwards will probably introduce final by default.
>>
>> Wait, does this mean we finally came to some kind of agreement on the
>> whole debate?
>
> Not finally... virtually :o).
>
> Andrei

Not bad. :-)

Joseph
February 25, 2014
Szymon Gatner, el 24 de February a las 11:48 me escribiste:
> On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:
> >On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:
> >>On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:
> >>>So 2.065 is not the one that will make class methods final by default?
> >>
> >>Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
> >
> >Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.

Wait, what? That was one of C++ biggest mistakes! You are seriously wanting to do that?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
O.K.
Just a little pinprick.
There'll be no more aaaaaaaaah!
But you may feel a little sick.
February 25, 2014
On Tuesday, 25 February 2014 at 00:09:45 UTC, Leandro Lucarella wrote:
> Szymon Gatner, el 24 de February a las 11:48 me escribiste:
>> On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:
>> >On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:
>> >>On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner
>> >>wrote:
>> >>>So 2.065 is not the one that will make class methods final by
>> >>>default?
>> >>
>> >>Correct. The pull for it is
>> >>https://github.com/D-Programming-Language/dmd/pull/2895
>> >
>> >Not really. This pull introduce the virtual keyword. The next step
>> >will afaik force you to write on every method if it is virtual or
>> >final. The step afterwards will probably introduce final by
>> >default.
>
> Wait, what? That was one of C++ biggest mistakes! You are seriously
> wanting to do that?

Don't worry:
https://d.puremagic.com/issues/show_bug.cgi?id=11616#c3
February 25, 2014
"Steven Schveighoffer"  wrote in message news:op.xbs1naiueav7ka@stevens-macbook-pro.local...

> A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident.
>
> But wild guesses don't help fix bugs :)

Walter + Andrei did it, and it was completely intentional, and it was known that it would break code.

https://github.com/D-Programming-Language/dmd/pull/3054 

February 25, 2014
On Tuesday, 25 February 2014 at 10:28:41 UTC, Daniel Murphy wrote:
> Walter + Andrei did it, and it was completely intentional, and it was known that it would break code.
>
> https://github.com/D-Programming-Language/dmd/pull/3054

I find it so ironical that Walter warns that this may break the code and few comments later says that more appropriate fix is not an option because "I don't want to break anything with this release" :P
February 25, 2014
On Tue, 25 Feb 2014 05:28:42 -0500, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xbs1naiueav7ka@stevens-macbook-pro.local...
>
>> A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident.
>>
>> But wild guesses don't help fix bugs :)
>
> Walter + Andrei did it, and it was completely intentional, and it was known that it would break code.

This was the wrong fix. Druntime should be modified to use TypeInfo.equals instead of TypeInfo.compare. Compare is no longer needed, since it's only used to check for equality.

Note that the docs say BOTH opEquals and opCmp should be specified, because either can be used.

I would suggest a proper interim fix is to only reject key types that define opEquals, but not opCmp. Then switch to using equals in druntime. Finally, get rid of AA's as a specialized type, map them cleanly to a template.

-Steve