Fix Issue 9489 - writeln of struct with disabled copy ctor

[berni44]

This fixes the first of the two errors described in issue 9489. However, I'm not sure, if I don't break something else. This is especially true for the ref in the foreach-loop, especially, because when I try to fix the second part too, I get a "Error: symbol _param_0 cannot be ref" pointing to this foreach.

Additionally, this produces a lot of merge conflicts with #8031.

So I'm quite unsure, if this should be merged. What do you think?

[dlang-bot]

Thanks for your pull request and interest in making D better, @berni44! 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

Auto-close	Bugzilla	Severity	Description
✓	9489	normal	writeln of struct with disabled copy ctor

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#8055"

[berni44]

This is especially true for the ref in the foreach-loop, especially, because when I try to fix the second part too, I get a "Error: symbol _param_0 cannot be ref" pointing to this foreach.

The testers complain about this too. Any ideas how to handle this more flexible? As far as I know, something like foreach (auto ref ... is not possible.

[berni44]

Seems to work now. I replaced the foreach over the variadic arguments with a static foreach over an index.

Anyway, please carefully check this, I don't know if this might have unwanted side effects.

[RazvanN7]

This seems like the correct fix. What happens if you use the normal foreach over an index? Also, could you include the reduced test case present in the bug report?

What part of this issue remains unfixed?

[berni44]

This seems like the correct fix. What happens if you use the normal foreach over an index?

I'm unsure, what you mean with that.

Also, could you include the reduced test case present in the bug report?

Sure. Soon.

What part of this issue remains unfixed?

typeof(scoped!Foo(1))[10] foos;
foreach (i, ref fi; foos)
    fi.x = i * 10;
writeln(foos); // Error

First of all it has to be

typeof(scoped!Foo(1))[10] foos = void;
foreach (i, ref fi; foos)
    fi.x = cast(int) (i * 10);
writeln(foos); // Error

With that I'll get an static assert error "Scoped[] must be an InputRange" - this seems to be something else.

[RazvanN7]

I'm unsure, what you mean with that.

What happens if you don't use static ?

[berni44]

"std/stdio.d(1689): Error: variable i cannot be read at compile time"

[RazvanN7]

Looks good to me

[RazvanN7]

With that I'll get an static assert error "Scoped[] must be an InputRange" - this seems to be something else.

Yeah, that's unrelated. You might want to update the commit message so that the bot auto-closes the issue.

[ibuclaw]

This introduced a regression: https://issues.dlang.org/show_bug.cgi?id=21920

[berni44]

This introduced a regression: https://issues.dlang.org/show_bug.cgi?id=21920

To be honest, I do not understand that error message ("Error: auto can only be used as part of auto ref for template function parameters"): The offending line is

void writeln(T...)(auto ref T args)

and thus auto is used as part of auto ref. Any ideas?

[CyberShadow]

auto ref works only with templated functions, because the argument becomes either ref or not depending on how the function called, like with IFTI. If you do writeln!int, then you explicitly instantiate the template, so it's no longer possible to do auto ref.

[berni44]

auto ref works only with templated functions, because the argument becomes either ref or not depending on how the function called, like with IFTI. If you do writeln!int, then you explicitly instantiate the template, so it's no longer possible to do auto ref.

Sorry, I still don't understand (maybe because I'm not familiar with IFTI - I do not even know what that is). I expect writeln!int to be instantiated as void writeln(int args)?!?

[CyberShadow]

No. When instantiating the template, the compiler must decide whether to instantiate the auto ref it as (int) or (ref int). Normally it can make that decision based on whether the call argument is an lvalue or not. With explicit instantiation, it does not have that information, hence the error.

void main()
{
	int v;

	void nonref(T)(T t) {}
	nonref(1); // OK
	nonref(v); // OK, by value (a copy occurs)
	alias nonref_int = nonref!int; // OK, void(int)

	void byref(T)(ref T t) {}
	byref(1); // error, requires ref
	byref(v); // OK, by ref
	alias byref_int = byref!int; // OK, void(ref int)

	void autoref(T)(auto ref T t) {}
	autoref(1); // OK, auto ref resolved as non-ref
	autoref(v); // OK, auto ref resolved as ref (no copy)
	alias autoref_int = autoref!int; // error, don't know what to do
}

[berni44]

	alias autoref_int = autoref!int; // error, don't know what to do

Ah, thanks, now I do understand (and I still think, the message could be improved).

Anyway, I fear, there is no possibility to tell the compiler to use the non-ref version as a default?

[CyberShadow]

Not that I know of (but I don't know many things).

I suggest reverting the change to fix the regression and add a test until a better solution is found.

[berni44]

I suggest reverting the change to fix the regression and add a test until a better solution is found.

Go on. As I wrote at the beginning of the PR: I feared something like that, but could not see it.