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
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 reply "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
parent reply =?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
next sibling parent reply 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=


en

 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=


lit'

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
parent reply "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
parent reply 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
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
prev 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