Two visual D suggestions:

[Alex]

On Thursday, 16 May 2019 at 05:55:23 UTC, Rainer Schuetze wrote:
> Hi,
>
> On 13/05/2019 21:58, Alex wrote:
>> 
>> A biggie:
>> 
>> 1. Visual D is not properly handling interfaces. If I declare 
>> an
>> interface variable, it simply treats it as a pointer without 
>> casting it
>> to it's class type. Since all interfaces are classes at run 
>> time, it
>> should do this internally and treat all interfaces as the 
>> classes that they
>> 
>> idata    0x000002a47bcc8510 {}    moduleX.idata
>> 
>> But if I cast idata to it's class then it shows everything as 
>> as expected.
>> 
>> This is tedious because it requires me to cast all interfaces 
>> and, at least for debugging purposes, makes interfaces a real 
>> PITA.
>> 
>> The debugger should easily be able to figure out the class of 
>> the type(use typeinfo/typeid/reflection or whatever).
>> 
>> Then just internally cast them to the class as if I did it in 
>> code(but still show it as an interface variable in the 
>> debugger).
>> 
>> example:
>> 
>> interface X;
>> class Y : X;
>> 
>> X x = new Y;
>> Y y = cast(Y)x;
>> 
>> x then is treated as a dumb ptr in the debug windows but y is 
>> treated correctly. Clearly they are identical.
>> 
>
> Will add to my TODO list. Evaluating the dynamic class already 
> works for classes, but not interfaces. The explicit cast in the 
> watch window (with fully qualified class name) works, too.

The problem is that there might be nested interfaces because of 
oop design. I strictly use interfaces so I'm always having to 
cast and create temp debug variables simply to get at the nested 
information.

So if a class contains another interface, it too should be casted 
and hence expandable.

Basically any interface listed in the debug should be treated as 
the class it expresses(most derived) even if it is part of 
another object.

That should add solve a lot of my problems in that area. I 
eagerly await the update! I just uninstalled vs2017 completely 
and installed 2019 + latest Visual D. So far everything has 
worked without a hitch.


> On 16/05/2019 06:34, Alex wrote:> Another suggestion! ;)
>>
>> One of the major issues I tend to have is not seeing a 
>> variable in the debug window. Would it be possible to be able 
>> to click on a variable in the editor and tell it to watch the 
>> variable?
>
> You can either right click the data tool tip and select "Add 
> watch", or drag the editor selection to the watch window.

When I do that it says symbol not found for any symbol not 
declared in the local context[specially in my case it is a 
callback in gtkd].

Is there any way for Visual D to detect the error and use a FQN 
if that solves it(the FQN is added internally so it doesn't 
clutter up the debug window).


If I add the module to the variable then it does show it.

myModule.Mystaticvar

works

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.

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)

Thanks!