[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |WORKSFORME --- Comment #20 from Walter Bright --- (In reply to Atila Neves from comment #19) > I can't reproduce the issue anymore. Then closing! --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #19 from Atila Neves ---
I can't reproduce the issue anymore. It helps that I now understand DIP1000 a
lot better than I did then. This seems to work fine:
int* gInts;
void main() @safe {
scope s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* ints;
auto ptr(this This)() @safe return scope { return ints; }
}
It lets you escape the pointer however if you replace `scope` with `auto` when
declaring `s`. In any case that'd be a different bug.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #18 from Mike Franklin ---
`scope ptr(this This)() { return ints; }` is ambiguous.
Did you mean `scope int* ptr(this This)() { return ints; }` or `int* ptr(this
This)() scope { return ints; }`
The former is supposed to apply `scope` to the return value while the latter
should `scope` to the implicit `ref this` parameter. See
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md#scope-function-returns
>From your explanation, I assume you're expecting `scope` to be inferred for the
implicit `ref this` parameter, correct?
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #17 from Atila Neves ---
After reading it again, I think the summary is (copied from earlier) this:
Function template => inferred attributes => scope. But fine, this compiles and
shouldn't:
--
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* ints;
scope ptr(this This)() { return ints; }
}
--
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 --- Comment #16 from Mike Franklin --- This thread is hard to follow. What's the cut-and-paste test case that demonstrates the problem? --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #15 from ag0aep6g ---
(In reply to Atila Neves from comment #13)
> > Apparently, DMD goes with infinite
>
> Only if it's a template this function.
No. My statement was about the lifetime of `malloc(...)`, which is called in
the constructor. The constructor doesn't have a template this parameter.
Your code has a template this parameter on the method `ptr`. But before `ptr`
comes into play, the lifetime of the field has already been set to infinite.
If we initialize the field to something with restricted lifetime, then leaking
`s.ptr` gets rejected as it should be:
const(int)* gInts;
void main() @safe
{
int x;
auto s = MyStruct();
gInts = s.ptr; /* Error: scope variable s assigned to gInts with longer
lifetime */
}
struct MyStruct
{
int* ints;
scope ptr(this This)() { return ints; }
}
The problem is that `ints` starts out with infinite lifetime when it's
initialized with a `malloc` call. `ptr` just passes the wrong lifetime on.
Also, if anything, it's the inference of the `return` attribute that's the
problem. The template this parameter merely triggers that. Empty template
parentheses or an `auto` return type have the same effect.
> As mentioned before, writing out the
> explicit instantitations for mutable, const and immutable doesn't compile.
[...]
> dmd is already doing the right thing with `scope ptr() { return ints; }`,
> `scope ptr() const { return ints; }` and `scope ptr() immutable { return
> ints; }` even if it's `auto s = MyStruct(10)` instead of `scope s =
> MyStruct(10)`.
As mentioned before, I can't reproduce this. Please post complete code.
With those definitions for `ptr` I get this code:
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct(10);
gInts = s.ptr;
}
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() { () @trusted { free(ints); }(); }
scope ptr() { return ints; }
scope ptr() const { return ints; }
scope ptr() immutable { return ints; }
}
And that compiles just fine. Because the `return` attribute is still inferred.
> It's only if `ptr` is a template this function this bug manifests. There's
> also a bug with `inout`, but that's another issue:
>
> https://issues.dlang.org/show_bug.cgi?id=17927
Yes, that's another issue. The method there doesn't have the `return`
attribute.
Maybe your point is that the `return` attribute shouldn't be inferred? Then
`ptr` wouldn't compile, but you could still make essentially the same mistake
by accessing `s.ints` directly.
> I didn't bother to respond to the rest of your analysis. The crux of the
> problem here is the interaction of a template function with DIP1000 and
> inferred lifetimes, and how it differs from the non-template functions.
My point is that changing the lifetime of `malloc(...)` could maybe fix this
issue and prevent the very similar mistake of copying `s.ints`, while still
allowing the `return` attribute to be inferred.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #14 from Mike Franklin --- (In reply to Atila Neves from comment #13) > It's only if `ptr` is a template this function this bug manifests I suspect that's due to the undocumented inference rules add by https://github.com/dlang/dmd/pull/8408 Note that in DIP25 it states: "Annotation are deduced for templates and lambdas, but must be explicit for all other declarations". --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #13 from Atila Neves ---
> Apparently, DMD goes with infinite
Only if it's a template this function. As mentioned before, writing out the
explicit instantitations for mutable, const and immutable doesn't compile.
That's the bug. Hence the issue title being "DIP1000 defeated if auto used
instead of scope in variable declaration with template this member function"
instead of "DIP1000 defeated if auto used instead of scope in variable
declaration".
dmd is already doing the right thing with `scope ptr() { return ints; }`,
`scope ptr() const { return ints; }` and `scope ptr() immutable { return ints;
}` even if it's `auto s = MyStruct(10)` instead of `scope s = MyStruct(10)`.
It's only if `ptr` is a template this function this bug manifests. There's also
a bug with `inout`, but that's another issue:
https://issues.dlang.org/show_bug.cgi?id=17927
I didn't bother to respond to the rest of your analysis. The crux of the
problem here is the interaction of a template function with DIP1000 and
inferred lifetimes, and how it differs from the non-template functions.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #12 from ag0aep6g ---
(In reply to Atila Neves from comment #11)
> > You're still just copying an `int*` around, which isn't unsafe.
>
> Of course it is, that's basically the whole point of Rust and DIP1000.
You're right. Of course DIP 1000 is about restricting how pointers can be
copied around. I was completely wrong here. Didn't really think in DIP 1000
terms. Sorry for the noise.
[...]
> From DIP1000:
>
> "For all global and static variables, lifetime is infinite."
> "For values allocated on the garbage collected heap, lifetime is infinite
> whilst reachability is dependent on the references in the program bound to
> those values."
>
> Algebra of lifetimes lists "*e", "new", "e[i]", "ArrayLiteral" and
> "ArrayLiteral[constant]" as the only expressions with infinite lifetime.
>
> And again:
>
> "A variable is inferred to be scope if it is initialized with a value that
> has a non-∞ lifetime."
>
>
> Therefore, since `auto s = MyStruct(10)` doesn't match any of the above
> conditions for an infinite lifetime, `auto` or `scope` should be the same
> thing.
DIP 1000 on `null`: "lifetime(null) is infinite". `null` is an instance of a
global, I guess.
On function calls, it says that the lifetime of the result is defined in the
"section dedicated to discussing functions". Unfortunately, that section
doesn't mention "lifetime" even once, and I find it rather hard to figure out
what the lifetime of a function call is supposed to be when the function body
isn't available for analysis.
So if we leave the pointer as `null`, it has infinite lifetime. And it's okay
to copy it around. This is what happens in all the posted snippets that don't
have a `malloc` call.
For `malloc(...)` it's not clear to me what the lifetime is supposed to be.
Apparently, DMD goes with infinite. The consequence is that the `free` call
always comes as a surprise to the compiler. I.e., calling `free` always breaks
the @trusted promise, and @safe becomes unreliable. The best we can do with
this is using an @trusted `free` anyway and containing the fallout.
What if `malloc(...)` had a zero lifetime instead? Then any access to a field
initialized from it would have to be @trusted, because its lifetime would
always be considered over. Since @safe code wouldn't be able to even look at
the field, @safe might stay reliable. I'm not sure if this could work out.
I suppose the goal is to somehow get access to the field with proper lifetime
(i.e. tied to the struct instance, if the destructor `free`s). With the current
implementation we might do it like this:
--- main.d
import the_ugly;
void* global;
void main() @safe
{
auto s = S(1);
int* local = s.p;
static assert(!__traits(compiles, global = s.p));
}
--- the_ugly.d
struct S
{
private int* p_;
int* p() return @safe
{
return p_;
}
this(int n) @trusted
{
import core.stdc.stdlib: malloc;
p_ = cast(int*) malloc(int.sizeof);
}
~this() @trusted
{
import core.stdc.stdlib: free;
free(p_);
}
}
The problem is of course that the whole module the_ugly must be verified
manually. @safe and attribute inference cannot be relied upon. That's brittle.
Could a method like `p` be written if DMD chose a zero lifetime for
`malloc(...)` instead of an infinite one? If so, that might be nice. `p` would
probably have to be @trusted, but @safe and attribute inference could be relied
upon for other methods and `p_` wouldn't even have to be private.
> > I'm not sure if I understand that correctly, but this compiles just fine:
>
> I'm arguing it shouldn't.
You said it "doesn't compile". Or more precisely: You described some code that
"doesn't compile" and I couldn't reproduce it from the description. If the code
you thought of is different from the snippet I pieced together, maybe show it
if it's interesting.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 --- Comment #11 from Atila Neves --- > @safe applies to functions/methods, not variables/fields. You can't forbid > @safe code from accessing a visible variable. Yes. But the code I presented is in one file for simplicity reasons. In real life MyStruct would be library code. The bug isn't about accessing variables. I understand what you mean about @safe messing up pointers, but I want to prevent client code from doing that, not my own implementation! > You're still just copying an `int*` around, which isn't unsafe. Of course it is, that's basically the whole point of Rust and DIP1000. > Without `scope` on the variable and without a destructor, there is no > indication that `s.ints` has a non-infinite lifetime. >From DIP1000: "For all global and static variables, lifetime is infinite." "For values allocated on the garbage collected heap, lifetime is infinite whilst reachability is dependent on the references in the program bound to those values." Algebra of lifetimes lists "*e", "new", "e[i]", "ArrayLiteral" and "ArrayLiteral[constant]" as the only expressions with infinite lifetime. And again: "A variable is inferred to be scope if it is initialized with a value that has a non-∞ lifetime." Therefore, since `auto s = MyStruct(10)` doesn't match any of the above conditions for an infinite lifetime, `auto` or `scope` should be the same thing. > I'm not sure if I understand that correctly, but this compiles just fine: I'm arguing it shouldn't. --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
anonymous4 changed:
What|Removed |Added
Hardware|x86_64 |All
OS|Linux |All
--- Comment #10 from anonymous4 ---
You can use a wrapper to mark data as unsafe:
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct(10);
gInts = s.ints; //error, can't call @system unwrap
}
struct MyStruct
{
import core.stdc.stdlib;
Unsafe!(int*) ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() { () @trusted { free(ints); }(); }
scope ptr(this This)() { return ints; }
}
struct Unsafe(T)
{
private T data;
@system:
@disable this(this);
this(T val){ data=val; }
void opAssign(T val){ data=val; }
T unwrap(){ return data; }
alias unwrap this;
}
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #9 from ag0aep6g ---
(In reply to Atila Neves from comment #8)
> > @safe code can mess with it
>
> No it can't, that's the point of @safe. Mess with it how?
@safe applies to functions/methods, not variables/fields. You can't forbid
@safe code from accessing a visible variable.
Example that's similar to your code:
int x = 41;
int y = 42;
struct S
{
int* p;
void t() @trusted
{
import core.stdc.stdlib: malloc;
if (p is null) p = cast(int*) malloc(2 * int.sizeof);
p[1] = 13;
}
void s() @safe { p = }
}
void main() @safe
{
S s;
s.s();
s.t();
assert(y == 42); /* Fails. */
}
Here, `t` assumes that `p` will be the result of `malloc`. But there is no way
in the language to force @safe code to respect that assumption. You can always
add an @safe method like `s` that messes with `p`, and then `t` will violate
safety.
DIP 1000 doesn't help here. It doesn't add a mechanism with which we could make
`p` inaccessible from `s`.
We're drifting off-topic topic here, though. Maybe we should move it to the
forum if we're not on the same page by now?
[...]
> --
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct();
> gInts = s.ptr;
> }
>
> struct MyStruct {
> int* ints;
> scope ptr(this This)() { return ints; }
> }
> --
You're still just copying an `int*` around, which isn't unsafe. `ptr` is
inferred as `return` so it's allowed to return `ints`. I suppose your point is
that `return` shouldn't be inferred? Maybe, but it's not obvious from the code.
A test case that shows actual damage (memory corruption) would go a long way.
[...]
> Because, from DIP1000:
>
> A variable is inferred to be scope if it is initialized with a value that
> has a non-∞ lifetime.
Without `scope` on the variable and without a destructor, there is no
indication that `s.ints` has a non-infinite lifetime.
> This very same code without a template this and instead manual
> instantiations of the three versions (mutable, const, immutable) doesn't
> compile _even_ if `auto` is used in the variable declaration.
I'm not sure if I understand that correctly, but this compiles just fine:
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* _ints;
auto ptr() { return _ints; }
auto ptr() const { return _ints; }
auto ptr() immutable { return _ints; }
}
> Furthermore, if `auto` was enough to get away from compiler checks, DIP1000
> would be useless since nobody is going to remember to write `scope`.
Copying a pointer isn't unsafe. There's no reason for the compiler to reject it
unless you add further restrictions by using `scope`.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #8 from Atila Neves ---
> @safe code can mess with it
No it can't, that's the point of @safe. Mess with it how?
> Why shouldn't this compile? There's no `scope` anywhere now (except maybe an
> inferred one)
Function template => inferred attributes => scope. But fine, this compiles and
shouldn't:
--
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* ints;
scope ptr(this This)() { return ints; }
}
--
> This makes sense to me. With `s` being `scope`, the compiler now checks it
> and its contents don't leave `main`.
Because, from DIP1000:
A variable is inferred to be scope if it is initialized with a value that has a
non-∞ lifetime.
This very same code without a template this and instead manual instantiations
of the three versions (mutable, const, immutable) doesn't compile _even_ if
`auto` is used in the variable declaration.
Furthermore, if `auto` was enough to get away from compiler checks, DIP1000
would be useless since nobody is going to remember to write `scope`.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #7 from ag0aep6g ---
(In reply to Atila Neves from comment #6)
> What's @trusted is that I'm calling `free` on the same pointer I allocated
> in the constructor, and the other thing needing checking is the postblit.
If you want to keep the @trusted promise, you can't rely on the pointer being
the same. @safe code can mess with it. There's no way around that. Maybe there
should be.
So what you do is this: You mark the `free` call as @trusted anyway, because
there's no other way. And then you have to check manually that your @safe code
doesn't mess with the pointer. Ideally, manual checks wouldn't be needed for
@safe code, but that's the price you pay for breaking the @trusted promise.
> This all is besides the point, given the code below has no @trusted
> anywhere, compiles, and shouldn't:
>
> ---
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct();
> gInts = s.ptr;
> }
>
> struct MyStruct {
> int* _ints;
> auto ptr(this This)() { return _ints; }
> }
> ---
Why shouldn't this compile? There's no `scope` anywhere now (except maybe an
inferred one). You're just copying an `int*` around. That's not against any
rules.
> As in the original report:
>
>
> * Adding a no-op destructor does nothing (i.e. the code still compiles):
>
> ~this() {} // ok but shouldn't be
Why shouldn't it compile with the destructor? The destructor is marked as @safe
and does nothing. So it's the same as not having a destructor at all, no?
> * Adding a no-op destructor annotate with scope causes a compile-time error:
>
> ~this() scope { }
>
> baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
Interesting. Looks like a `scope` destructor also makes any instances
implicitly `scope`. I don't think I understand DIP 1000 or its implementation
well enough to this. DIP 1000 doesn't seem to mention it, as far as I see.
> * With no destructor at all but replacing `auto` with `scope` also fails to
> compile:
>
> scope s = MyStruct();
>
> baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
This makes sense to me. With `s` being `scope`, the compiler now checks it and
its contents don't leave `main`.
If `s` is not `scope`, there's no indication that its contents shouldn't be
allowed to leave `main`.
> Weirdly enough, changing `gInts` to a static array and returning &_ints[0]
> in ptr also fails to compile;
Do you mean making `_ints` a static array (e.g., `int[1] _ints;`)? If so, the
code effectively becomes:
const(int)* gInts;
void main() @safe
{
int _ints;
gInts = &_ints;
}
Leaking a reference to a local variable is not allowed, of course. It's very
different from copying a pointer.
If you really mean making `gInts` a static array, could you post the full code?
I don't understand what you mean in that case.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #6 from Atila Neves ---
I typed the code from memory and made a mistake. Yes, it's supposed to be
`.ptr`. There's no way I can call core.stdc.stdlib.free without @trusted
_somewhere_, since `free` isn't @safe - free(42) is obviously going to crash.
What's @trusted is that I'm calling `free` on the same pointer I allocated in
the constructor, and the other thing needing checking is the postblit.
This all is besides the point, given the code below has no @trusted anywhere,
compiles, and shouldn't:
---
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct();
gInts = s.ptr;
}
struct MyStruct {
int* _ints;
auto ptr(this This)() { return _ints; }
}
---
As in the original report:
* Adding a no-op destructor does nothing (i.e. the code still compiles):
~this() {} // ok but shouldn't be
* Adding a no-op destructor annotate with scope causes a compile-time error:
~this() scope { }
baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
* With no destructor at all but replacing `auto` with `scope` also fails to
compile:
scope s = MyStruct();
baz.d(7): Error: scope variable s assigned to gInts with longer lifetime
Weirdly enough, changing `gInts` to a static array and returning &_ints[0] in
ptr also fails to compile;
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #5 from ag0aep6g ---
(In reply to Atila Neves from comment #4)
> I made a mistake when I posted the code. This compiles but shouldn't (the
> only difference is removing `scope` from the destructor).
[...]
> @safe:
>
> const(int)* gInts;
>
> void main() {
> auto s = MyStruct(10);
> gInts = s.ints;
> }
>
> struct MyStruct
> {
> import core.stdc.stdlib;
> int* ints;
> this(int size) @trusted { ints = cast(int*) malloc(size); }
> ~this() { () @trusted { free(ints); }(); }
> scope ptr(this This)() { return ints; }
> }
You're not calling `ptr`. `main` reads the `ints` field directly. That's
allowed, of course. D has no way of preventing @safe code from accessing a
local struct's field.
If the code is changed to actually call `ptr`, it still compiles. Maybe that
shouldn't be allowed, but it's not obvious to me from the code. If this is a
safety violation, we should be able to show something like memory corruption,
mutating immutable data, stuff like that.
As it is, the only obvious safety violation is in the @trusted destructor. It
assumes that the `ints` field is not accessible from @safe code, but that's
wrong. Unfortunately, misusing @trusted like that is necessary for stuff like
this, but it still means breaking the @trusted promise. The consequence is that
(at least) the whole module must be checked manually to uphold the assumption
of the badly @trusted method. One cannot rely on @safe to catch mistakes in
that area. So if none of MyStruct's methods can be allowed to return `ints`,
because the destructor relies on that, then that must be checked manually.
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183
--- Comment #4 from Atila Neves ---
I made a mistake when I posted the code. This compiles but shouldn't (the only
difference is removing `scope` from the destructor).
I also surrounded the call to `free` with @trusted instead of the whole
constructor.
@safe:
const(int)* gInts;
void main() {
auto s = MyStruct(10);
gInts = s.ints;
}
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() { () @trusted { free(ints); }(); }
scope ptr(this This)() { return ints; }
}
--
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #3 from ZombineDev --- It seems that you're not passing -dip1000 on the command-line. I'm also on Arch Linux. Here's what I get: ~/dlang/install.sh dmd source ~/dlang/dmd-2.081.2/activate dmd -dip1000 scope.d scope.d(7): Error: scope variable s assigned to gInts with longer lifetime --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 --- Comment #2 from Atila Neves --- I used dmd 2.081.2. I just tried it again and it compiles. Just in case there's something wrong with the Arch Linux package, I used dmd.081.2 from install.sh. Same result. I also tried the 2.082.0 beta 1. Same thing. --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from ag0aep6g --- Doesn't compile for me (2.081.2). I get: test.d(7): Error: scope variable s assigned to gInts with longer lifetime https://run.dlang.io/is/74B2qq --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 Atila Neves changed: What|Removed |Added Keywords||safe --
