You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As should be clear, the intended type of stdout is File, but I want the code to be type-generic for various reasons, mainly testing.
In the event (as will be the case) that WriteType resolves to more than one type, it seems that providing hover and completion for stdout is undecidable even with compiler support. A least-common-denominator approach for completion names (covering the subset of methods/fields/etc the types have in common) might work ok, but there's the question of the canonical documentation for hovering.
So even given the expected improvements in comptime analysis, it might remain useful to allow an annotation like this:
It also has the advantage that it would work right now, and is relatively straightforward to add in comparison to full compiler integration.
Another strength of this approach is that someone reading the file can see what stdout is "supposed" to be, clearly there are a lot of ways to document that but this is one good option.
I think we'd need two ways to do this, type parameters applied to a field is the most common case but it isn't the only one. This won't work because of "pointless discard":
_=WriteType; // zls type-hint: std.fs.File
I think it would be a bit strange to apply it to lines where the type is actively used in any way. That leaves something like a comment on its own line that looks like this:
// zls type-hint: WriteType = std.fs.File
Maybe that isn't the perfect syntax but something like that.
It's definitely a brute-force solution, but perhaps that's a good thing here.
The text was updated successfully, but these errors were encountered:
I didn't see this in the open issues, apologies if I missed it.
I have some code like this, in the usual sort of type-returning function:
As should be clear, the intended type of
stdout
isFile
, but I want the code to be type-generic for various reasons, mainly testing.In the event (as will be the case) that
WriteType
resolves to more than one type, it seems that providing hover and completion forstdout
is undecidable even with compiler support. A least-common-denominator approach for completion names (covering the subset of methods/fields/etc the types have in common) might work ok, but there's the question of the canonical documentation for hovering.So even given the expected improvements in comptime analysis, it might remain useful to allow an annotation like this:
It also has the advantage that it would work right now, and is relatively straightforward to add in comparison to full compiler integration.
Another strength of this approach is that someone reading the file can see what
stdout
is "supposed" to be, clearly there are a lot of ways to document that but this is one good option.I think we'd need two ways to do this, type parameters applied to a field is the most common case but it isn't the only one. This won't work because of "pointless discard":
I think it would be a bit strange to apply it to lines where the type is actively used in any way. That leaves something like a comment on its own line that looks like this:
// zls type-hint: WriteType = std.fs.File
Maybe that isn't the perfect syntax but something like that.
It's definitely a brute-force solution, but perhaps that's a good thing here.
The text was updated successfully, but these errors were encountered: