On 4/8/2012 4:56 PM, Andrei Alexandrescu wrote:
> On 4/8/12 6:11 PM, David Nadlinger wrote:
>> The thing is that some parts of Thrift are rather metaprogramming-heavy,
>> and these parts at the same time are quite well covered by its test
>> suite. Thus, it does rather well in finding related DMD regressions – at
>> least I don't recall a recent release where this hasn't been the case.
>
> Interesting. I wonder whether it's worth making building and testing Thrift a part of the normal benchmarks.
>

My experience is we are far, far, far better off having a test suite composed of isolated test cases than some large, complex library. The reason is because if the library fails, it's simply hell for anyone trying to distill the bug out of it. Also, large libraries give the illusion of coverage, but in reality tend to be some small subset repeated over and over. And they add a lot of time to the running of the test suite.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2012$BG/(B4$B7n(B9$BF|(B10:07 Jonathan M Davis <jmdavisProg@gmx.com>:
> There really should be errors for opEquals, opCmp, toString, and toHash with incorrect signatures,

It is difficult to detect *incorrect signatures*, because compiler cannot judge it is a mistake of programmer, or is intended one of him.

> and for any of them that need multiple overloads, it
> should complain not only if any of the overloads are incorrect but if any are
> missing. The fact that it's sort that's complaining makes it very hard to
> determine what's actually wrong.

At least, we should fix const system holes (e.g bug1824 - Object not const correct) before adding this kind of enforcements. Otherwise compiler may block some user codes that picks the const system holes but works as expected.

Kenji Hara
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, April 09, 2012 10:26:37 kenji hara wrote:
> 2012年4月9日10:07 Jonathan M Davis <jmdavisProg@gmx.com>:
> > There really should be errors for opEquals, opCmp, toString, and toHash with incorrect signatures,
> 
> It is difficult to detect *incorrect signatures*, because compiler cannot judge it is a mistake of programmer, or is intended one of him.

It doesn't matter what the programmer intended. If specific signatures are required for these functions, then the compiler knows exactly what they should look like, and if they don't match, then they're wrong.

> > and for any of them that need multiple overloads, it
> > should complain not only if any of the overloads are incorrect but if any
> > are missing. The fact that it's sort that's complaining makes it very
> > hard to determine what's actually wrong.
> 
> At least, we should fix const system holes (e.g bug1824 - Object not const correct) before adding this kind of enforcements. Otherwise compiler may block some user codes that picks the const system holes but works as expected.

We should enforce whatever is currently required by the compiler. That enforcement can change when the requirements change. For instance, if a struct's opEquals must currently look like

bool opEquals(const S rhs) const {}
bool opEquals(const ref S rhs) const {}

then it should be an error if it doesn't. And if the requirements change so that a struct's opEquals should look like

bool opEquals(const S rhs) @safe const pure nothrow {}
bool opEquals(const ref S rhs) @safe const pure nothrow {}

then at that point, it'll complain if they don't look like that. Right now, the compiler is requiring things for these functions but not always giving errors when stuff doesn't match (or good ones when it does give errors), making it hard to get it right.

Obviously, the compiler can't require that all of these functions look like they're going to look a release or two from now, since that's going to change as we iron things out to make it possible for them to have the signatures that we want, but since the compiler _does_ have requirements for them (even if they're incomplete compared to what they will be), I don't see why the compiler shouldn't be complaining if they don't match what it currently requires.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/8/2012 5:39 PM, kenji hara wrote:
>
> I think the cause of issue 7864 is same.

So should we mark 7864 as invalid?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Yes, I've commented and marked as resolved-invalid.

Kenji Hara

2012$BG/(B4$B7n(B9$BF|(B10:43 Walter Bright <walter@digitalmars.com>:
>
>
> On 4/8/2012 5:39 PM, kenji hara wrote:
>>
>> I think the cause of issue 7864 is same.
>
> So should we mark 7864 as invalid?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 9 Apr 2012, at 0:33, David Nadlinger wrote:
> On 8 Apr 2012, at 20:44, David Nadlinger wrote:
>> Still working on tracking down the mixin forward ref related regression, […]
>
> Another bug probably somehow related to the Thrift test suite breakage; at least, I am having a hard time figuring out what is really going on with the confusion it causes: http://d.puremagic.com/issues/show_bug.cgi?id=7862

Hopefully the last Thrift blocker:
http://d.puremagic.com/issues/show_bug.cgi?id=7868

David
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Thank you. That leaves 7815.

On 4/8/2012 7:17 PM, kenji hara wrote:
> Yes, I've commented and marked as resolved-invalid.
>
> Kenji Hara
>
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/8/2012 8:33 PM, David Nadlinger wrote:
>
> Hopefully the last Thrift blocker:
> http://d.puremagic.com/issues/show_bug.cgi?id=7868
>

I marked it as invalid with the corrected code.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Jonathan M Davis" <jmdavisProg@gmx.com>
> On Saturday, April 07, 2012 22:15:53 Walter Bright wrote:
>> http://ftp.digitalmars.com/dmd2beta.zip
>
> With this release, it looks like opCmp (like opEquals) needs to have overloads
> which take both const ref and non-ref, which is fine. But the obvious way to
> implement this seems to result in infinite recursion:
>
> import std.string;
>
> struct S
> {
>    string s;
>
>    int opCmp(S rhs) const
>    {
>        return opCmp(rhs);
>    }
>
>    int opCmp(const ref S rhs) const
>    {
>        return cmp(s, rhs.s);
>    }
> }
>
> void main()
> {
>    assert(S("h") < S("w"));
>    assert(S("w") > S("h"));
>
>    auto h = S("h");
>    auto w = S("w");
>
>    assert(h < w);
>    assert(w > h);
> }
>
>
> Shouldn't the non-ref opCmp being calling the ref one and not itself? Right
> now, it's resulting in a segfault, because it's calling itself. Is this a bug,
> or is it expected behavior? I'm inclined to say that it's a bug and a rather
> serious issue in light of needing to duplicate functions like opEquals and
> opCmp. But I may be missing something here.
>

I ran into that problem too. I ended up having to have the two opCmp's, and make them both forward to an opCmp_. And then repeat the whole pattern for opEquals and at least one other thing. One hell of a mess just to use basic operator overloading.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Walter Bright" <walter@digitalmars.com>
> Thank you. That leaves 7815.
>

And this:

[2.059 Beta] Changelog should clearly mention struct literal/opCmp/opEquals/toHash changes
http://d.puremagic.com/issues/show_bug.cgi?id=7833

There are MAJOR breaking changes in 2.059 regarding those things. These need to be reflected in the documentation and the changelog or people are going to be very, very lost.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta