[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #14 from Dlang Bot  ---
dlang/dlang.org pull request #3619 "[spec/function] Improve `return` struct
method attribute docs" was merged into master:

- 17763b0db20cc9978cc8729bd13f96f2987b by Nick Treleaven:
  [spec/function] Document `return` parameters without `scope`

  Part of Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
  missing.

  Add 'Struct Return Methods' subheading.

https://github.com/dlang/dlang.org/pull/3619

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #13 from Dlang Bot  ---
@ntrel created dlang/dlang.org pull request #3619 "[spec/function] Document
`return` parameters without `scope`" fixing this issue:

- [spec/function] Document `return` parameters without `scope`

  Fixes Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
  missing.

https://github.com/dlang/dlang.org/pull/3619

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #12 from Nick Treleaven  ---
If you define `front` as `return`, *not* `return scope`:

Elem front() @safe return

You get an error for:

elem = l.front;

I think that fixes this issue, though that feature may need documenting.

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Paul Backus  changed:

   What|Removed |Added

 CC||snarwin+bugzi...@gmail.com

--- Comment #11 from Paul Backus  ---
One workaround for this is to pass the value to a callback as a scope
parameter, rather than returning it:

---
void withList(alias callback)()
{
scope l = (() @trusted => List(malloc(1)))();
callback(l);
}

void test() @safe
{
Elem elem;
withList!((scope ref l) {
elem = l.front; // scope variable `l` assigned to `elem` with longer
lifetime
});
}
---

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P3  |P4

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #10 from Dlang Bot  ---
dlang/dmd pull request #13926 "Revert "fix Issue 17934 - [scope] scopeness
entrypoint for unique/ref…" was merged into master:

- 70d7a4799c62598d0f4ddc2d7ed3fcb0fd19e6f9 by Dennis Korpel:
  Revert "fix Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
missing"

  This reverts commit 18ad1685dcdca65070f7a1d89efa4410a5936895.

https://github.com/dlang/dmd/pull/13926

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #9 from Nick Treleaven  ---
(In reply to Mike Franklin from comment #7)
> What about having `scope` apply to return values of functions, so `list()`
> could be written as `scope List list() @trusted`?

That might work there, but what about when a method wants to specify that the
return value is `scope`? The `scope` attribute would be interpreted as applying
to the `this` reference, when we might need a smaller scope. I really wish
`this` parameter qualifiers were only allowed after the parameter list to avoid
ambiguities.

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #8 from Dlang Bot  ---
@dkorpel created dlang/dmd pull request #13926 "Revert "fix Issue 17934 -
[scope] scopeness entrypoint for unique/ref…" mentioning this issue:

- Revert "fix Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
missing"

  This reverts commit 18ad1685dcdca65070f7a1d89efa4410a5936895.

https://github.com/dlang/dmd/pull/13926

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #7 from Mike Franklin  ---
(In reply to Martin Nowak from comment #0)

> /**
>   There seems to be now way to write this functions so
>   that the compiler infers the return value as scope.
>  */
> List list() @trusted
> {
> return List(malloc(1));
> }
> 
> void test() @safe
> {
> Elem elem;
> {
> //scope l = list(); // works with explicit scope
> auto l = list(); // not inferred as scope
> elem = l.front; // escapes, b/c l isn't scoped
> }
> }

Why does `scope` need to be inferred?  What's wrong with the user being
required to attribute `scope` to the declaration.

What about having `scope` apply to return values of functions, so `list()`
could be written as `scope List list() @trusted`?

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Walter Bright  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #6 from Walter Bright  ---
New fix:

https://github.com/dlang/dmd/pull/8369

done by adding 'scope' to struct declaration.

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

Walter Bright  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/18ad1685dcdca65070f7a1d89efa4410a5936895
fix Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted missing

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/18ad1685dcdca65070f7a1d89efa4410a5936895
fix Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted missing

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7284

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #2 from Walter Bright  ---
It sounds like the solution is to infer 'scope' for a struct instance on the
stack if it has a destructor.

--

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17934

--- Comment #1 from Martin Nowak  ---
Even if `l` is not inferred as scope, it should be a local with limited
lifetime.
The return value `l.front` should have that same lifetime b/c of `return
scope`.
Both of them should be shorter as `elem`, hence assignment should fail.

--