My bad, there are two bugs.
All of the above opSlice methods should fail to compile, but on the mutable and cost method do, the inout silently compiles, even though it escapes a field.
All of the methods should and do compile with return scope (even the inout one).
The compiler doesn't infer scope for their returned slice and thus allows escaping that.
Comment #2 by bugzilla — 2017-10-23T02:28:55Z
Changing the @trusted to @safe makes the first example fail to compile with:
test.d(6): Error: pointer slicing not allowed in safe functions
Changing String to:
struct String {
inout(char)[] opSlice() inout scope @safe {
return ptr[];
}
char[] ptr;
}
And it now compiles, as it should. Will look at the rest.
Comment #3 by bugzilla — 2017-10-23T04:57:54Z
Back to the process of stripping things down to the essentials:
--------------------
const(char)* foo1(scope const(char)* ptr) @safe { return ptr; }
inout(char)* foo2(scope inout(char)* ptr) @safe { return ptr; }
--------------------
Produces the expected error messages:
test.d(1): Error: scope variable ptr may not be returned
test.d(3): Error: scope variable ptr may not be returned
So add in a bit of complexity:
--------------
struct String {
const(char)* mem1() const scope @safe { return ptr; }
inout(char)* mem2() inout scope @safe { return ptr; }
char* ptr;
}
--------------
Produces:
test.d(2): Error: scope variable this may not be returned
The message for mem2() is not generated, so the issue is with the 'inout' on the 'this' parameter.
Comment #4 by bugzilla — 2017-10-23T05:35:17Z
It turns out that:
struct String {
inout(char)* mem2() inout scope @safe { return ptr; }
char* ptr;
}
not issuing an error is actually correct, because a parameter that is `ref inout` is inferred to be `return`, and the `this` parameter for `mem2` is `ref inout`.
Comment #5 by bugzilla — 2017-10-23T05:40:17Z
For the unittest, the `dup` does not create data with limited lifetime, so `s` is not inferred as `scope`, and `escape` is free to escape it.
It's complicated, but the compiler is working as it is supposed to.
Thanks for investigating, so now it's reduced to the old problem that the scope system does not allow to define entry points.
Of course in real life this is using malloc instead of GC'ed dup, but it's not possible to contain the former.
Comment #11 by atila.neves — 2018-08-16T18:29:16Z
I don't understand how it's possible that making it `inout` is correct inference. This allows for code that looks @safe but isn't. This really shouldn't compile:
@safe:
const(int)* gInt;
void main() {
auto s = Struct();
gInt = s.ptr; // ARGH!
}
struct Struct {
int* ints;
this(int size) {
import core.stdc.stdlib;
ints = () @trusted { return cast(int*) malloc(size); }();
}
~this() {
import core.stdc.stdlib;
() @trusted { free(ints); }();
}
scope inout(int)* ptr() inout {
return ints;
}
}
And yet it does. I guess I'll have to define 3 methods for mutable, const and immutable if I want to not crash.
Comment #12 by schveiguy — 2018-08-20T14:04:03Z
(In reply to Walter Bright from comment #4)
> It turns out that:
>
> struct String {
> inout(char)* mem2() inout scope @safe { return ptr; }
> char* ptr;
> }
>
> not issuing an error is actually correct, because a parameter that is `ref
> inout` is inferred to be `return`, and the `this` parameter for `mem2` is
> `ref inout`.
What? ref inout should NOT be inferred as return. inout is a pattern match on the mutability of the parameters, it does not necessarily imply that it is part of the return type.
This can be handy when trying avoid code duplication when the const/immutable is nested under several indirections (including ref).
Reopening, the original problem is not fixed. The error case added tests for compiling the functions, but doesn't test that the result of the inout function is scope (it should be).
Comment #13 by slavo5150 — 2019-09-04T13:18:08Z
Inferring `return` on `this` for anything marked with `inout` appears to be the cause of issue 20149.
Comment #14 by bugzilla — 2020-03-04T10:01:21Z
(In reply to Steven Schveighoffer from comment #12)
> ref inout should NOT be inferred as return. inout is a pattern match
> on the mutability of the parameters, it does not necessarily imply that it
> is part of the return type.
inout is deliberately inferred as return. It's the way the language currently works. To change it please make an enhancement request, as such should be discussed on its own merits.
Comment #15 by schveiguy — 2020-03-04T23:07:17Z
Fixing the resolution, as the original bug was not invalid. If I have time, I'll try to remember what this was about and open another enhancement request.