Open MariaSolOs opened 2 months ago
completions for integer types were intentionally removed in #1681. I am not necessarily against adding them back but the PR has given a good reason for their removal. If we were to add them back, we would to find a way to make them less annoying when they are unwanted.
@Techatrix as someone that just started learning Zig, the lack of valid type completions does feel a bit odd. However I also understand how they might become annoying when other completion options are preferred... Perhaps we could bring them back but tweak their priority/order in the completion list so that they're shown further down? Or maybe further tune when to show them, such as in when completing a type annotation.
Perhaps we could bring them back but tweak their priority/order in the completion list so that they're shown further down?
If we can ensure that other completions take priority over things like integer types then I don't see why we couldn't add them back. A while ago, I experimented with improving the order of completion items. I did not quite get it to be what I wanted but I just haven't spent much time on it.
Related #1792
Or maybe further tune when to show them, such as in when completing a type annotation.
filtering completions when completing a type annotation is definitely something that should be considered. This is similar to what I have a proposed in #1845 since type annotation also have Result Locations. I will add another example to that issue.
@Techatrix that sounds reasonable! I definitely think that an specific change for this isn't worth it if there's already ongoing work/discussions around completions :)
Integer type completions for u
and i
seem like a non-starter, there are more than 64 thousand integer types in Zig. Floats don't have that issue, but I agree with #1681, typing the full name of a float type is faster and less distracting than selecting a completion. Providing only the "natural" i
and u
types (8, 16, 32, 64, u21
as a special case) seems wrong to me, for reasons which are hard to pinpoint, but it's basically that the others are valid so it's weird to leave them off.
There may be circumstances where in fact only a subset of those integer types are valid completions, but I'm struggling a bit to pinpoint when that might be. A case could be made that []|
having a const u8
completion is so common that it's worth special casing, just as a user affordance. I'm narrowly against that actually, upon reflection, but getting into why would take me more off topic.
Either way, const u8
is eight keystrokes, u32
is two keys after the u
, and unless it was right on top that's less typing than selecting and accepting the completion.
I do recognize that integer type completions might be somewhat useful for learners, but I think it's better to favor intermediate and advanced users on this point, where such completions would just be noise. Even for learners, the absence of oddball types like, say, u42
, might imply that they don't exist, when they do. So in balance I favor not adding them back.
Zig Version
0.13.0
Zig Language Server Version
Not sure how to check this
Client / Code Editor / Extensions
Neovim
Steps to Reproduce and Observed Behavior
Start typing
const x: u
. No completions for the variable type are shown.Expected Behavior
For completions like
u16
to be displayed.Relevant log output
No response