cat > bug.d << CODE
import core.stdc.stdlib;
struct List
{
Elem front() @safe return scope
{
return Elem(data);
}
~this() @trusted scope
{
free(data);
data = null;
}
@disable this(this);
private:
void* data;
}
struct Elem
{
private:
void* data;
}
/**
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
}
}
CODE
dmd -c -dip1000 bug.d
----
Repeatedly ending up with this problem. It doesn't seem possible to contain allocated data, as there is now way to enforce that the call-site uses a scope variable.
Comment #1 by code — 2017-10-24T22:46:11Z
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.
Comment #2 by bugzilla — 2017-10-27T23:19:55Z
It sounds like the solution is to infer 'scope' for a struct instance on the stack if it has a destructor.
(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`?
Comment #8 by dlang-bot — 2022-03-30T08:51:31Z
@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
Comment #9 by nick — 2022-03-30T12:29:06Z
(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.
Comment #10 by dlang-bot — 2022-03-31T08:14:56Z
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
Comment #11 by snarwin+bugzilla — 2023-05-29T14:07:10Z
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
});
}
---
Comment #12 by nick — 2023-05-31T10:28:32Z
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.
Comment #13 by dlang-bot — 2023-05-31T11:35:16Z
@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
Comment #14 by dlang-bot — 2023-07-14T18:44:35Z
dlang/dlang.org pull request #3619 "[spec/function] Improve `return` struct method attribute docs" was merged into master:
- 17763b0db20cc9978c0000c8729bd13f96f2987b 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
Comment #15 by robert.schadek — 2024-12-13T18:55:00Z