On Thursday, 23 June 2022 at 00:45:09 UTC, Steven Schveighoffer
wrote:
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.
It is confusing because it introduces flow typing without having
flow typing. So this is messing up the user’s mental model of the
type system, this is a basic usability flaw.
Track the object instead and don’t change the type of the pointer
to scope.
If D wants to do flow typing, do it properly and make it clear to
the user. It would be a good feature to have, but it would become
D3.
