auto-resolve `@property`?

[TurkeyMan]

Was there ever a time when VisualD automatically resolved @property-ies when hovering? I have distinct memories of that functionality from many years back, but maybe I'm wrong.
I often think it would be nice to hover over length when length is a @property and the like. I use a lot of bit-stuffing tricks for embedded array lengths and the like.

[rainers]

The discussion about this feature prompted the implementation of function execution in the debugger, see #241. Missing appropriate debug information there was never an automatic detection of properties, though. When debugging the dmd frontend, it also annoys me to see function pointers instead of the actual values for some bitfields implemented as properties (though not annotated that way).

When hovering, maybe the text passed to the debugger for evaluation can be modified, using semantic analysis to pass the @property information with it, e.g. as a modifier similar to ",!". That might also make it accessible in the watch window allowing it to be evaluated automatically.

[TurkeyMan]

@property appears to affect the mangling of the symbol name; is that not sufficient information? Depending on semantic seems more brittle than depending on the symbol name?

[rainers]

@property appears to affect the mangling of the symbol name; is that not sufficient information?

It appears that this can actually work (but is restricted to extern(D) functions). I have implemented it in https://github.com/dlang/visuald/releases/tag/v1.4.1-beta3. Please note that it has to be enabled in the debugger options. As with functions explicitly called in the watch expressions execution is currently not asynchronous which should not be an issue when shown as a tool tip. The auto window shows properties, too, though.

As purity is also detectable from the mangling, it could also be restricted to functions with that annotation (and const). That could avoid inadvertently executing functions that might modify the program state.

[TurkeyMan]

Yeah it certainly occurred to me that maybe it should be restricted to const and/or pure functions. const seems like a no-brainer, pure makes sense too, but a lot of people don't bother with pure even when it's appropriate, which means maybe evaluation will fail when it should work because people didn't annotate correctly? What do you reckon; risk vs convenience?

[rainers]

I thought about making it a multiple state option: never, pure const @property, const @property, @property. It's probably too risky to allow pure const only, too, but as @property has almost no effect for the language, it is also not used very often.

[TurkeyMan]

What do you reckon the risk for pure const alone is? You're right that @property is rarely used... I would basically just use it to activate this debug feature, but that doesn't scale when libraries are used.

[rainers]

Methods implementing "logical const" (e.g. mutating some internal cache) could be annotated pure const.

[TurkeyMan]

how could a method with no arguments and const this mutate an internal cache? Unless via a global, and pure inhibits that.
That said, this is one of the biggest frictions in D; it's common to want to manage internal caching for performance reasons, but we can't express those 'logical' const/purity states in D...

[rainers]

how could a method with no arguments and const this mutate an internal cache?

It would have to cast away const on this or one of its sub-components. You can also break purity by casting function pointers at compile time (can be considered a bug in the compiler, but avoids having to manipulate the mangling).

[TurkeyMan]

Right. I think we can accept that if someone does that, it's intentional and they know what they're doing...

[rainers]

Right. I think we can accept that if someone does that, it's intentional and they know what they're doing...

Agreed.

Wanted to use this feature on the dmd frontend, just to be hit by dlang/dmd#21382 ...

[rainers]

This is now available in https://github.com/dlang/visuald/releases/tag/v1.4.1-beta4