Qualify GC range add and remove as pure

[nordlow]

Enables dlang/phobos#4832 (comment)

Should I make the other members in GC pure aswell?

[andralex]

This is dependent upon dlang/dlang.org#1528, which makes these too functions non-strongly pure function and requires them to be called compulsively.

[rainers]

This is dependent upon dlang/dlang.org#1528, which makes these too functions non-strongly pure function and requires them to be called compulsively.

What's in that definition that would remove strong purity? These functions don't have parameters with mutable references.

[nordlow]

Ping, @andralex, what to do with this?

[andralex]

OK, thanks.

[dnadlinger]

Sorry, just to double-check: As Rainer mentioned above, where does dlang/dlang.org#1528 exempt these from memoization?

[schveiguy]

where does dlang/dlang.org#1528 exempt these from memoization?

I agree, I can't see where that is. The parameter has no mutable indirections, and it returns void.

[dnadlinger]

(@andralex)

[andralex]

@schveiguy could you please add the appropriate language to the spec? Thanks!

[dnadlinger]

What even would be the appropriate wording that allows discarding of calls to strongly pure functions with return values, but requires those without to be kept? This doesn't seem obvious – neither how to phrase it, nor necessarily that this is what we want.

[andralex]

@klickverbot @schveiguy agreed it's not obvious at all! Because it isn't obvious I'm counting on you to find a solid solution to what indeed is a difficult issue. Clearly there is a practical need for it because people want to use reference counted objects (including containers) in pure functions.

The productive way to frame this is as a problem that needs a solution, not a change that must be rejected. Looking forward to your insights.

[schveiguy]

My response is simply that we don't need to alter the spec, we don't need to merge this PR, in order to get reference counted objects to work in pure code.

As I've said elsewhere, we should let impure functions be impure, and when we need to break the rules, we do so locally, not for everyone using Phobos or druntime.

In other words, for reference counting, we have a function incRef that's not technically pure, but can be assumed pure by adding a pragma(mangle, ...) version that adds whatever we need to get it to work. In that context, there will be mutable indirections (the reference count), and no elision will occur. Inside that impure function, we can call addRange just fine (and it won't be elided by the compiler).

If this isn't acceptable, you will have to find someone else to write the desired (and IMO incorrect) rule, as I have no idea how to do it properly. Keep in mind that the simple envisioned cases are never the ones that cause problems. It's the unexpected corner cases where things break down. Where we have the compiler inferring attributes, and then acting on those attributes, it's very difficult to come up with a rule that allows this PR to accomplish its goal in all cases.

[andralex]

@schveiguy a pure void function is a contradiction in terms. The situation can be detected trivially by the compiler, and the question is how to handle it. The obvious thing would be to statically disallow it. But perhaps the compiler can do something much better about it.

[schveiguy]

A pure void function that takes no mutable parameters (as addRange does) is a contradiction. I agree the compiler can statically disallow it, or statically elide it. Preferably, it would be just elided, as sometimes these are the result of templates, and I've experienced the horrors of making someone check all that stuff manually.

But as I said before, if you wrap such a function, it changes the dynamics, without really changing anything. You can't depend on the call going through. For instance:

pure void foo(const int *a); // does impure things
pure int foo2(const int *a) { foo(a); return 0; }

// under some proposed rule, these always get called
foo(a);
foo(a);

// But not these? It is the same thing essentially!
foo2(a);
foo2(a);

This is a silly, non-real example. But these kinds of pathological cases happen when templates are involved, and we have wrapping going on all over the place, with ranges, UFCS, etc.

The rule doesn't work IMO, because it can't be reasoned about with the other rules of pure.

I strongly suggest we try doing reference counting with local workarounds vs. affecting the whole language.