Represent optional JSON boolean as `*bool` in Go to avoid altering messages when deserializing and re-serializing
- Dominant language
- Go
- Stars
- 140
- Forks
- 29
- PR merge metrics
- No merged PRs in 30d
Description
Currently, go-dap reprents JSON booleans as `bool`, regardless of whether they are optional or required. As a result, a message that does not set a boolean will have it set to `false` when deserialized and then re-serialized.
Unfortunately, it is not always specified in the DAP protocol how to treat a missing boolean field. Take for example https://microsoft.github.io/debug-adapter-protocol/specification#message:
```
/**
* If true show user.
*/
showUser?: boolean;
```
Strictly speaking (because it is not "Iff" aka "if and only if"), this comment does not specify what should happen when this is unset. And sure enough VS Code interprets missing as true for this field:
https://github.com/microsoft/vscode/blob/27a0cbb26647670ad719bcb47e2d1ca4cee133bf/src/vs/workbench/contrib/debug/browser/debugService.ts#L631
We are deserializing and serializing all messages in a proxy for logging and sanitization, so go-dap turning unset into false is a problem for us.
This could be fixed by representing optional booleans as `*bool` (and then using `omitempty`), similar to how we represent optional nested messages as `*struct`. Unfortunately this is a breaking change as users of the library would then need to dereference the pointer as they read and assign, and handle the nil case explicitly. However, I think this is the correct handling.
What do you think?
Contributor guide
Research direction
The issue names no files or tests; start by reviewing go-dap's message definitions and the proxy serialization path described in the report. Identify optional boolean fields that need pointer representations, verify that missing values survive deserialization and re-serialization, and account for the breaking API change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100