Annotate std/json.d to please dlang/dmd#12520

[nordlow]

Part of #8076

[dlang-bot]

Thanks for your pull request and interest in making D better, @nordlow! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#8088"

[Geod24]

How can it be scope given it is stored in the object ?

[nordlow]

Thanks. I'll check.

[dkorpel]

It can't, but the assignment happens in a @trusted lambda so the compiler doesn't complain.

[nordlow]

Deleted my two previous comments. Afaict, we have a catch 22 here; qualifying v as return in

@property string str(return string v) pure nothrow @nogc @safe
{
    assign(v);
    return v;
}

and reverting to non-scope arg in

private void assign(T)(T arg)

fails to be build on master (uses -dip1000) as

std/json.d(164): Error: scope variable `v` assigned to non-scope parameter `arg` calling std.json.JSONValue.assign!string.assign

because incorrect inference of scope on v because str is qualified as pure.

This passes with dlang/dmd#12520, though.

One way around this is to create two definitions of str; one that works with correct (non-)scope inference of parameters of pure functions (dlang/dmd#12520) and one that compiles with the incorrect (master).

A simpler approach I vote for is to temporarily qualify str, object and array as @trusted and revert these back to @safe as soon dlang/dmd#12520 has been merged.

What do you think, @Geod24, @thewilsonator, @dkorpel ?

[nordlow]

I just pushed a forced update that uses @trusted along with a TODO for now for the cases described above. This std/json.d builds locally with both master and dlang/dmd#12520.

[RazvanN7]

I agree that this is a better alternative, however, we must not forget about it.

[nordlow]

I agree that this is a better alternative, however, we must not forget about it.

Thank you!