www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - default implemented opAssign purity

reply "Dan" <dbdavidson yahoo.com> writes:
Is the default implemented opAssign really pure and therefore 
should be considered such.

The code below works. If you turn off the static if, it will fail 
with:

Error: pure function 'opAssign.foo' cannot call impure function 
'opAssign.S.opAssign'.

Also, in case the answer is no and default implemented opAssign 
must remain impure, is there a standard way, in a member function 
to do like:

auto ref opAssign(S other) pure {
    blit other into this
    call this(this)
}

Thanks
Dan

-------------
import std.stdio;
import std.algorithm;

struct S {
   char[] c;
   this(this) pure { c = c.dup; }
   static if(1) {
     auto ref opAssign(S other) pure { c = other.c.dup; return 
this; }
   }
}

S foo(S s) pure {
   S other;
   other = s;
   return other;
}

void main() {
   S s;
   S another = foo(s);
}
Dec 02 2012
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 2 December 2012 at 13:07:42 UTC, Dan wrote:
 Is the default implemented opAssign really pure and therefore 
 should be considered such.

 The code below works. If you turn off the static if, it will 
 fail with:

 Error: pure function 'opAssign.foo' cannot call impure function 
 'opAssign.S.opAssign'.

Default opAssign function is described here: http://dlang.org/struct.html. It calls dtor and postblit (if any) which are impure. Even if you mark them pure, you still implicitly call opAssign which is not marked as pure. This can be probably enhanced.
 Also, in case the answer is no and default implemented opAssign 
 must remain impure, is there a standard way, in a member 
 function to do like:

 auto ref opAssign(S other) pure {
    blit other into this
    call this(this)
 }

 Thanks
 Dan

Are you looking for this http://dpaste.dzfl.pl/7ee27db2 ?
Dec 02 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/02/2012 07:50 AM, Dan wrote:
 On Sunday, 2 December 2012 at 14:13:34 UTC, Maxim Fomin wrote:

 Are you looking for this http://dpaste.dzfl.pl/7ee27db2 ?

I did not know you could call __postblit - that's cool.

I did not know either. :) I was going to ask "Is __postblit a part of the language spec" but then I found TypeInfo.postblit: http://dlang.org/phobos/object.html#postblit I hoped the following might work: typeid(this).postblit(&this); But no, it is not pure: Error: pure function 'opAssign' cannot call impure function 'postblit' Ali
Dec 02 2012
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Sunday, 2 December 2012 at 14:13:34 UTC, Maxim Fomin wrote:
 On Sunday, 2 December 2012 at 13:07:42 UTC, Dan wrote:

 Default opAssign function is described here: 
 http://dlang.org/struct.html. It calls dtor and postblit (if 
 any) which are impure. Even if you mark them pure, you still 
 implicitly call opAssign which is not marked as pure. This can 
 be probably enhanced.

Exactly. I am suggesting that the default opAssign be marked pure, if in fact it is. I think it is. This way we would not need to implement an opAssign and duplicate code to just to get a pure version of opAssign.
 Also, in case the answer is no and default implemented 
 opAssign must remain impure, is there a standard way, in a 
 member function to do like:

Are you looking for this http://dpaste.dzfl.pl/7ee27db2 ?

I did not know you could call __postblit - that's cool. So, that is almost it. Ideally I want Don't Repeat Yourself (DRY). If I have implemented a postblit I don't want to duplicate my dups in an opAssign. I just want to invoke the postblit, which you have done, after a proper full blit of S. The only issue is how to actually blit other into this. Instead of manually "blitting" each field, which opens the door for bugs when new fields are added, something more like this, which unfortunately does not compile because of pure. http://dpaste.dzfl.pl/d8937f43 Thanks Dan
Dec 02 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 11:12:45 Ali =C3=87ehreli wrote:
 On 12/02/2012 07:50 AM, Dan wrote:
  > On Sunday, 2 December 2012 at 14:13:34 UTC, Maxim Fomin wrote:
  >> Are you looking for this http://dpaste.dzfl.pl/7ee27db2 ?
  >=20
  > I did not know you could call __postblit - that's cool.
=20
 I did not know either. :)
=20
 I was going to ask "Is __postblit a part of the language spec" but th=

 I found TypeInfo.postblit:
=20
    http://dlang.org/phobos/object.html#postblit
=20
 I hoped the following might work:
=20
          typeid(this).postblit(&this);
=20
 But no, it is not pure:
=20
    Error: pure function 'opAssign' cannot call impure function 'postb=

Pretty much none of the built-in stuff like that is pure or nothrow rig= ht now.=20 It needs to be fixed. - Jonathan M Davis
Dec 02 2012
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Sunday, 2 December 2012 at 19:12:46 UTC, Ali Çehreli wrote:
 On 12/02/2012 07:50 AM, Dan wrote:

 I was going to ask "Is __postblit a part of the language spec" 
 but then I found TypeInfo.postblit:

   http://dlang.org/phobos/object.html#postblit

 I hoped the following might work:

         typeid(this).postblit(&this);

 But no, it is not pure:

   Error: pure function 'opAssign' cannot call impure function 
 'postblit'

I see that for this postblit: this(this) { c = c.dup; } But if I do it like this: this(this) pure { c = c.dup; } it seems to honor it (i.e. no compile error): http://dpaste.dzfl.pl/00674ebb For me the problem is opAssign - I don't want to write it to get pure. I will if I have to - but if I do I don't want to be duping all fields. If I have to do that I'll give up on pure. The reason I'm in this rabbit hole is trying to get a const static and assigning it from a pure function seemed to be the trick to allow it at compile time. Thanks, Dan
Dec 02 2012
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Sunday, 2 December 2012 at 19:34:46 UTC, Jonathan M Davis 
wrote:
 Pretty much none of the built-in stuff like that is pure or 
 nothrow right now.
 It needs to be fixed.

Maybe I'm naive, but problems with lax specification of pure, const and immutable should be low hanging fruit - relatively easy to fix and good bang for buck. The problem with being lax in phobos or object is that it gives a sense of false advertising. Great language features with great promise as described by TDPL, but can't use it if not done everywhere.
Dec 02 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 23:04:29 Dan wrote:
 On Sunday, 2 December 2012 at 19:34:46 UTC, Jonathan M Davis
 
 wrote:
 Pretty much none of the built-in stuff like that is pure or
 nothrow right now.
 It needs to be fixed.

Maybe I'm naive, but problems with lax specification of pure, const and immutable should be low hanging fruit - relatively easy to fix and good bang for buck. The problem with being lax in phobos or object is that it gives a sense of false advertising. Great language features with great promise as described by TDPL, but can't use it if not done everywhere.

What about the specification is lax? pure, const, and immutable are quite well defined. The problem here is that it's stuff in druntime that needs to be fixed which very few people can do, and it often runs into other problems which makes making any of the changes incredibly difficult. For instance, to fix the current AA implementation requires a ton of work, because it affects all kinds of stuff all over the place in druntime, so the result is that none of it is getting fixed right now, which obviously isn't good. Some of this stuff is getting fixed incrementally, but it's definitely taking longer than would be desirable, and while some of it may be low hanging fruit, a lot of it really isn't because of how much stuff is affected. Small changes quickly become huge ones when dealing with druntime changes - especially with stuff like pure, const, and nothrow. - Jonathan M Davis
Dec 02 2012
prev sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Sunday, 2 December 2012 at 22:19:18 UTC, Jonathan M Davis 
wrote:
 On Sunday, December 02, 2012 23:04:29 Dan wrote:

 What about the specification is lax? pure, const, and immutable 
 are quite well
 defined.

Sorry - by specification I was not thinking D Language Specification but more API or library specification. More accurately I should have said lax signatures.
 The problem here is that it's stuff in druntime that needs to 
 be fixed
 which very few people can do, and it often runs into other 
 problems which
 makes making any of the changes incredibly difficult. For 
 instance, to fix the
 current AA implementation requires a ton of work, because it 
 affects all kinds
 of stuff all over the place in druntime, so the result is that 
 none of it is
 getting fixed right now, which obviously isn't good.

Fair enough.
 Some of this stuff is getting fixed incrementally, but it's 
 definitely taking
 longer than would be desirable, and while some of it may be low 
 hanging fruit,
 a lot of it really isn't because of how much stuff is affected. 
 Small changes
 quickly become huge ones when dealing with druntime changes - 
 especially with
 stuff like pure, const, and nothrow.

Dec 02 2012