April 06, 2012

On 4/6/2012 10:17 PM, Jonathan M Davis wrote:
> If this is really that big an issue in general, then it would probably be better to temporarily make it so that toHash doesn't insist an being pure until 2.060,

I already checked that in. It's in the new beta 2.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Friday, April 06, 2012 22:39:51 Walter Bright wrote:
> On 4/6/2012 10:17 PM, Jonathan M Davis wrote:
> > If this is really that big an issue in general, then it would probably be better to temporarily make it so that toHash doesn't insist an being pure until 2.060,
> 
> I already checked that in. It's in the new beta 2.

Good to know. Hopefully that solves Vladimir's issue for now, but clearly we need to make sure that stuff like Appender and to!string can be pure soon (preferably for 2.060). Some progress has been made in that direction with this release, but we have quite a ways to go.

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

April 06, 2012

On 4/6/2012 9:04 PM, Jonathan M Davis wrote:
> My _guess_ as to why toHash now requires purity is because the current AA implementation relies on it as part of the transition to proper constness and purity in Object and whatnot (the implementation isn't currently templated, so it can't take advantage of purity inference). 

The reason for purity is so that it can be used in functional programming paradigms. FP is becoming increasingly important, and we need to make the foundational bits of Phobos as pure as possible.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 07, 2012
On 7 April 2012 08:09, Walter Bright <walter@digitalmars.com> wrote:
>
>
> On 4/6/2012 9:04 PM, Jonathan M Davis wrote:
>>
>> My _guess_ as to why toHash now requires purity is because the current AA implementation relies on it as part of the transition to proper constness and purity in Object and whatnot (the implementation isn't currently templated, so it can't take advantage of purity inference).
>
>
> The reason for purity is so that it can be used in functional programming paradigms. FP is becoming increasingly important, and we need to make the foundational bits of Phobos as pure as possible.

I think the challenge is that it's a bit of a chicken-and-egg
situation: some of the functions require things like toHash to be
pure, but things like toHash require the functions to be pure.
Makes it a bit hard to incrementally add pure. Might be necessary to
change everything simultaneously.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Friday, April 06, 2012 23:09:01 Walter Bright wrote:
> On 4/6/2012 9:04 PM, Jonathan M Davis wrote:
> > My _guess_ as to why toHash now requires purity is because the current AA implementation relies on it as part of the transition to proper constness and purity in Object and whatnot (the implementation isn't currently templated, so it can't take advantage of purity inference).
> 
> The reason for purity is so that it can be used in functional programming paradigms. FP is becoming increasingly important, and we need to make the foundational bits of Phobos as pure as possible.

Yes. But with structs, it's often not as big an issue, because templates are used which means that the attributes are inferred. If the AA implementation were templated, then this probably wouldn't be an issue for structs at all. It would be pure if the struct's toHash were pure but would still work as impure if it weren't. With classes, however, it's definitely all or nothing, thanks to inheritance.

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

April 08, 2012
On Sat, 07 Apr 2012 08:46:35 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Good to know. Hopefully that solves Vladimir's issue for now, but clearly we need to make sure that stuff like Appender and to!string can be pure soon (preferably for 2.060). Some progress has been made in that direction with this release, but we have quite a ways to go.

Thanks for your help, everyone. I've made some progress with the latest DMD.

text(int) is not nothrow. I think it should be nothrow as well as pure. This is easy to work around, though.

I've hit the mysterious opEquals problem again (this time with nothrow instead of pure). I'm going to try minimizing my codebase and find the cause.

In case of errors like "function a cannot call function b because reasons", it would be helpful to also print b's location.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 08, 2012
On Sun, 08 Apr 2012 00:18:41 +0300, Vladimir Panteleev
<thecybershadow.lists@gmail.com> wrote:

> I've hit the mysterious opEquals problem again (this time with nothrow instead of pure). I'm going to try minimizing my codebase and find the cause.

I found the problem. The cause is that Object's opEquals is not nothrow,
another chicken-and-egg problem.

class C
{
	override bool opEquals(Object o) const nothrow
	{
		return true;
	}
}

struct S
{
	C o;

	bool opEquals(ref const S s) const nothrow
	{
		return o == s.o;
	}
}

What's even worse, is that overriding Object's opEquals with a nothrow
implementation still causes the error. I guess that's because a==b calls
the free opEquals function from object.d, which is not nothrow.

-- 
Best regards,
   Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 07, 2012
On Sunday, April 08, 2012 02:15:42 Vladimir Panteleev wrote:
> On Sun, 08 Apr 2012 00:18:41 +0300, Vladimir Panteleev
> 
> <thecybershadow.lists@gmail.com> wrote:
> > I've hit the mysterious opEquals problem again (this time with nothrow instead of pure). I'm going to try minimizing my codebase and find the cause.
> 
> I found the problem. The cause is that Object's opEquals is not nothrow, another chicken-and-egg problem.
> 
> class C
> {
> 	override bool opEquals(Object o) const nothrow
> 	{
> 		return true;
> 	}
> }
> 
> struct S
> {
> 	C o;
> 
> 	bool opEquals(ref const S s) const nothrow
> 	{
> 		return o == s.o;
> 	}
> }
> 
> What's even worse, is that overriding Object's opEquals with a nothrow implementation still causes the error. I guess that's because a==b calls the free opEquals function from object.d, which is not nothrow.

Object's functions have been messed with much yet. toHash is the only one which has any attributes on it (@trusted and nothrow), and it doesn't have all of the ones that it's supposed to yet. I believe that toString, opEquals, opCmp, and toHash will all become @safe const pure nothrow in one sweep, which will break a _lot_ of code. But that transition hasn't been completed yet. Work was done on that this release, but it'll be completed for 2.060 at the earliest.

So, the situation with opEquals on classes should not have changed at all with this release. It's changed somewhat with structs ( http://d.puremagic.com/issues/show_bug.cgi?id=7833 ), but not classes. So, I wouldn't have expected your code to break due to anything related to opEquals and classes. Maybe something was changed in how attributes are dealt with on overridden functions though. That would affect opEquals along with every other overidden function.

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

April 07, 2012
My plan to ease into this is not going well.

At the moment, either remove the nothrow from S.opEquals, or wrap the throwing == with a try...catch(Exception).

On 4/7/2012 4:15 PM, Vladimir Panteleev wrote:
> class C
> {
>     override bool opEquals(Object o) const nothrow
>     {
>         return true;
>     }
> }
>
> struct S
> {
>     C o;
>
>     bool opEquals(ref const S s) const nothrow
>     {
>         return o == s.o;
>     }
> } 
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 09, 2012
On Sun, 08 Apr 2012 09:34:48 +0300, Walter Bright <walter@digitalmars.com> wrote:

> My plan to ease into this is not going well.
>
> At the moment, either remove the nothrow from S.opEquals, or wrap the throwing == with a try...catch(Exception).

I have hit another problem:

import std.algorithm;

struct S
{
	int n;

	string toString()
	{
		return null;
	}
}


void main()
{
	S*[] all;
	sort!q{a.n > b.n}(all);
}

Compiling the above program prints a wall of error messages.

I don't think this is related to the pure/nothrow. Seems to be an unrelated regression from 2.058.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta