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 guess the intention is to
break less existing code.
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.
-Steve
