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

Status
REOPENED
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-10-24T22:42:26Z
Last change time
2024-12-13T18:55:00Z
Keywords
pull, safe
Assigned to
Walter Bright
Creator
Martin Nowak
Moved to GitHub: dmd#17821 →

Comments

Comment #0 by code — 2017-10-24T22:42:26Z
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.
Comment #3 by bugzilla — 2017-11-04T09:01:31Z
Comment #4 by github-bugzilla — 2017-11-10T11:28:29Z
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
Comment #5 by github-bugzilla — 2017-12-18T22:56:43Z
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
Comment #6 by bugzilla — 2018-06-18T21:21:23Z
New fix: https://github.com/dlang/dmd/pull/8369 done by adding 'scope' to struct declaration.
Comment #7 by slavo5150 — 2018-08-31T09:19:01Z
(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
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17821 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB