Variable in DAP has evaluateName which is used when evaluateRequest is made. This is particularly useful when accessing nested fields in a complex data structure.

t := struct { I int } { I: 123 }

For example, Go debug adapter represents t's field I as a Variable like the following

{"variables":[{"name":"I","value":"1","presentationHint":{},"evaluateName":"t.I","variablesReference":0}

That allows us compact and comprehensible display of the struct variable while still allowing us to get the correct syntax to locate the nested field.

I noticed however, setVariable request uses name of Variable, not evaluateName.
https://github.com/microsoft/vscode/blob/5207b984029a2fa8eb4133f594218d25f5325e29/src/vs/workbench/contrib/debug/common/debugModel.ts#L248

[<- from client]{"seq":15,"type":"request","command":"setVariable","arguments":{"variablesReference":1002,"name":"I","value":"2","format":{}}}

We can make the debug adapter to recompute the evaluateName by looking up data with "variablesReference" and "name" info. But, it's sad that the debug adapter has already provided the fully qualified name to vscode but has to recompute it.

I'd argue using evaluateName here is reasonable given that - it tells us how to access the variable for read, and so it should be good for write too.

If it's too late to change setVariable request's name to be evaluateName, is it possible to add an optional evaluateName to the setVariable request?

--
Originally filed as microsoft/vscode#120774
to see if this requires a spec change or changing vscode's debug code to reuse existing name for different purpose is sufficient.