On Thursday, 23 June 2022 at 00:45:09 UTC, Steven Schveighoffer
wrote:
On 6/22/22 5:44 PM, Dukc wrote:
On Wednesday, 22 June 2022 at 21:07:50 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven
Schveighoffer wrote:
The part about `scope` being shallow. This is a problem.
One thing that will be confusing to most users is that it
appears to be using "taint" rather than proper flow analysis
on the pointed-to-object?
```d
int* test(int arg1, int arg2) {
int* p = null;
p = &arg1;
p = new int(5);
return p; // complains about p being scope
}
```
I'd personally prefer if variable `scope` auto-inference
worked only in the declaration, not later assignments.
I agree.
I think this is the better option. Either that, or that when it
returns `p` that trumps any possible `scope` inference.
Imagine you have a function like this:
```d
int foo()
{
int x = 0;
x = long.max;
x = 2;
return x;
}
```
Now today, this causes an error on the assignment to
`long.max`, because obviously `x` is an int. But what if,
instead, the compiler decides to backtrack and say "actually,
if I make x a `long`, then it works!", and *now*, at the end,
says "Oh, actually, you can't return a long as an int, what
were you thinking?!"
This is the equivalent here, you declare something *without*
scope, assign it to something that is *not* scope, and then
because sometime later you assigned it to something that *is*
scope, it goes back and rewrites the declaration as if you did
make it scope, and then complains to you that the magic trick
it tried is not valid.
This is going to be one of the most confusing features of
DIP1000.
Plus that the error message just sounds like a compiler bug. It
says that variable `p` is `scope`, but nowhere in the source does
it say that. The error message should say that assignment `p =
&arg1;` makes the variable `scope`.
(An alternative is to give a warning on `p = &arg1;`.)
-Johan
