Re: [DIP1000] Something I don't quite understand regarding 'scope'
On Monday, 29 June 2020 at 06:21:43 UTC, ag0aep6g wrote: Since `local` and `writeln` are templates, the attributes for their parameters are inferred from their bodies. `local!(int*)` doesn't do anything with the parameter, so it's inferred as `scope`. `writeln!(int*)` apparently does something that prevents `scope` from being inferred. Thanks. It would appear indeed that inference fails for some reason. Explicitly marking args as 'scope' for `writeln` and `File.write` lets them compile. I wonder if there's a way to find exactly what it is in either of those that prevents the compiler from inferring 'scope'.
Re: [DIP1000] Something I don't quite understand regarding 'scope'
On 29.06.20 02:28, Stanislav Blinov wrote: void local(Args...)(Args args) { } void main() @safe { import std.stdio; scope int* p; local(p); // Ok writeln(p); // Error: scope variable p assigned to non-scope parameter _param_0 calling std.stdio.writeln!(int*).writeln } The signatures of `std.stdio.writeln` and `local` are the same (see `writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call to `local` compiles, while the call to `writeln` doesn't. Since `local` and `writeln` are templates, the attributes for their parameters are inferred from their bodies. `local!(int*)` doesn't do anything with the parameter, so it's inferred as `scope`. `writeln!(int*)` apparently does something that prevents `scope` from being inferred.
[DIP1000] Something I don't quite understand regarding 'scope'
void local(Args...)(Args args) { } void main() @safe { import std.stdio; scope int* p; local(p); // Ok writeln(p); // Error: scope variable p assigned to non-scope parameter _param_0 calling std.stdio.writeln!(int*).writeln } The signatures of `std.stdio.writeln` and `local` are the same (see `writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call to `local` compiles, while the call to `writeln` doesn't. Is that an instance of [2]? [1] https://github.com/dlang/phobos/blob/v2.092.1/std/stdio.d#L3865 [2] https://issues.dlang.org/show_bug.cgi?id=20023