Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no type completions for primitive types like u16, u32, f32 etc. #1995

Open
MariaSolOs opened this issue Aug 11, 2024 · 5 comments
Open

no type completions for primitive types like u16, u32, f32 etc. #1995

MariaSolOs opened this issue Aug 11, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@MariaSolOs
Copy link

MariaSolOs commented Aug 11, 2024

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

@MariaSolOs MariaSolOs added the bug Something isn't working label Aug 11, 2024
@Techatrix
Copy link
Member

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.

@MariaSolOs
Copy link
Author

MariaSolOs commented Aug 11, 2024

@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.

@Techatrix
Copy link
Member

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 Techatrix changed the title Missing type completions no type completions for primitive types like u16, u32, f32 etc. Aug 11, 2024
@Techatrix Techatrix added enhancement New feature or request and removed bug Something isn't working labels Aug 11, 2024
@MariaSolOs
Copy link
Author

@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 :)

@mnemnion
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants