Two visual D suggestions:

[Rainer Schuetze]

On 16/05/2019 11:19, Alex wrote:
> Could Visual D just not internally add this for me? We know it has the
> info because I can do go to definition and it takes me to the right
> module, so it seems it could first check if it gets
> 
> D0013: Error: Symbol not found
> 
> and if so then auto-resolve the name by fully qualifying it and then
> trying again...
> 
> Should be pretty simple and a just a few lines of code, assuming the FQN
> is easy to get.

Unfortunately, it is not. The semantic engine and the debugger extension
are unaware of each other. Even if they are, symbol lookup might slow
down the debugging experience quite a bit.

IIRC GDC emits symbol lookup information (e.g. imports) to the debug
info. I think this should happen with DMD or LDC, too.

> 
> Hypothetically if I were generating a module at runtime with a random
> name for some purpose, then it would be a pain to have to explicitly
> specify a variable in that module because it wouldn't be correct on the
> next run. Automatically resolving it would solve this problem though.
> 
> Also, if it fails with the FQN then it could try to use outer context,
> then this, then super, etc... (and the Type in the autos/watch would
> show the full info like super.SuperWorkedVar as to inform the programmer
> which qualification worked in case there was ambiguity so they could try
> an explicit case)

Actually it already does this inside extern(D) unctions (but it might
not work for all symbols due to a change in the mangling). It doesn't
find symbols that are visible through imports.