View mode: basic / threaded / horizontal-split · Log in · Help
December 02, 2012
default implemented opAssign purity
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);
}
December 02, 2012
Re: default implemented opAssign purity
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 ?
December 02, 2012
Re: default implemented opAssign purity
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
December 02, 2012
Re: default implemented opAssign purity
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
December 02, 2012
Re: default implemented opAssign purity
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
December 02, 2012
Re: default implemented opAssign purity
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
December 02, 2012
Re: default implemented opAssign purity
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.
December 02, 2012
Re: default implemented opAssign purity
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
December 02, 2012
Re: default implemented opAssign purity
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.
>
Top | Discussion index | About this forum | D home