roslyn: CompletionLists don't help make clear which object properties are nullable and which aren't.
A picture to help show what i mean:
In this completion list, it is not easy to figure out which of these properties are required (i.e. must not be null) and which are optional. Even though this property is marked as having a nullable return type, it’s necessary to go and investigate the quick-info tooltip for each to discover that. Contrast that with the TypeScript model of optionally-nullable properties:
Here it’s trivial to see which properties would be required or not. Just look for the ? at the end of the property name.
This ‘lifting’ of the information to be directly exposed on the completion list is super useful and makes it very clear what you really need to be providing, versus what you can optionally provide.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 24 (22 by maintainers)
Let’s step back:
Here’s my general feedback. Coding with nullable today is difficult and feels like it has more that interferes with flow. I made some proposals that i thought might help but i am not wedded to them. However, i think effort should be made to help with the problem even if imperfect. I think having more information rather than less can help allow people to grok more at a glance instead of requiring more overt effort.
Finally, i brought up TS not because i feel that C#'s nullable is an exact match for TS’s optional. But because all the above applies in the TS case as well and demonstrates that good enough (though technically inaccurate at times) solutions can be highly beneficial. In other words, trying to make something exact and perfect and totally in line with the language is not necessary, and can actively hamper and limit the benefits we can provide the user and the typing experience. TS is used to demonstrate that that’s the case in a similar (but not identical) scenario.