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.

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.

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.

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`.

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.

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

Spec pull: https://github.com/dlang/dlang.org/pull/1914

Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/3f7544f355eacc0ad390a89b1bc07ca2dbcf835e
fix Issue 17927 - [scope]  parameter value can be escaped via return

https://github.com/dlang/dmd/commit/b46ac59c637723877b52b98ed50167e0f68aca5d
Merge pull request #7235 from WalterBright/fix17927

fix Issue 17927 - [scope]  'scope inout' parameter value can be escaped via return

Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/3f7544f355eacc0ad390a89b1bc07ca2dbcf835e
fix Issue 17927 - [scope]  parameter value can be escaped via return

https://github.com/dlang/dmd/commit/b46ac59c637723877b52b98ed50167e0f68aca5d
Merge pull request #7235 from WalterBright/fix17927

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.

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.

(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).

Inferring `return` on `this` for anything marked with `inout` appears to be the cause of issue 20149.

(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.

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.