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);
}

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 ?

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

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

On Sunday, December 02, 2012 11:12:45 Ali Çehreli 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 ?
>  >
>  > 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'

Pretty much none of the built-in stuff like that is pure or nothrow right now. It needs to be fixed.

- Jonathan M Davis

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

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.

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

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.
>