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
{{ message }}
Repository navigation
Improve hover/completion for function-valued aliases (tear-offs) #6081
When a function is exposed as a top-level alias via a tear-off:
constInitWindow= proxy.InitWindow;
Dart currently shows:
void Function(int, int, String) InitWindow
and only exposes the function type.
However, much of the original function metadata is lost:
Parameter names are not shown.
The symbol is rendered as a variable instead of a callable function.
For example, hovering over the original function:
const
func
voidInitWindow(
int width,
int height,
String title,
)
shows:
void InitWindow(
int width,
int height,
String title,
)
with parameter names.
But hovering over:
constInitWindow= proxy.InitWindow;
shows only:
void Function(int, int, String) InitWindow
and loses:
width
height
title
While forwarding functions are a workaround, they become verbose when optional positional parameters, named parameters, or default values are involved, since the entire signature must be repeated.
constInitWindow= proxy.InitWindow;
is much more concise than:
voidInitWindow(
int width,
int height,
String title,
) => proxy.InitWindow(width, height, title);
I'll defer to @bwilkerson, but don't know if enough information is retained to support this. The code const InitWindow = proxy.InitWindow; isn't really creating an alias, it's declaring a variable InitWindow that has the the same type and value as proxy.InitWindow. The positional parameters names are not part of the type - if it wasn't for const you would be able to reassign it to another function with different parameter names:
varInitWindow= proxy.InitWindow;
InitWindow= (int notWidth, int notHeight, String notTitle) {}; // This is valid because the names are not part of the type
Hovering over a variable shows its type, not value.
It looks like the JS/TS tooling might capture the parameter names along with the type even though they're not part of the type. This can lead to inconsistencies, for example:
Here, the signature help is showing the wrong names compared to the function that would be called. It's a contrived example, but shows why it might not be sound to do this (at least for non-const variables).
For non-const variables, I agree that highlighting var func as a variable is useful because it signals that the binding can be reassigned. But for const func = someFunction;, the binding cannot change, so from the user's perspective it behaves no differently from the function itself. Highlighting it as a plain variable feels more confusing to me than highlighting it like the function it refers to.
The analyzer doesn't retain enough information for us to be able to display the names of positional parameters when all we have is a function type. I don't think it keeps enough information even in the case of a const variable.
As a work-around, you could consider using named parameters, such as
The analyzer doesn't retain enough information for us to be able to display the names of positional parameters when all we have is a function type.
Is it likely this would ever change? I don't know the scale of the work or whether if there are any other benefits to doing so. If not, I'll close this.
I doubt it, but we could double check on the sdk repo.
Because the names aren't used in any type-based operations (equality, subtype, etc.) keeping them wouldn't add any value to the analyzer, but would increase the amount of memory used. Some function types do point to a declaration from which they were derived, but using that information when it's available would lead to an inconsistent experience, so it isn't clearly the right solution.
I've opened dart-lang/sdk#63792 for discussion (I also included some notes about testing I did - it seems like Signature Help is already showing the parameter names in the cases I could come up with to test).
Activity
FMorschel commentedon Jun 9, 2026
CC @bwilkerson
DanTup commentedon Jun 9, 2026
I'll defer to @bwilkerson, but don't know if enough information is retained to support this. The code
const InitWindow = proxy.InitWindow;isn't really creating an alias, it's declaring a variableInitWindowthat has the the same type and value asproxy.InitWindow. The positional parameters names are not part of the type - if it wasn't forconstyou would be able to reassign it to another function with different parameter names:Hovering over a variable shows its type, not value.
While it might be possible to look up the value for a
constvariable, presenting this as a real function/method might go against the goal "The tooling should never mislead the user about the syntax or semantics of the language".dzylikecode commentedon Jun 9, 2026
Could we take JavaScript's behavior as a reference here?
addAliasis present as a function instead of a variable.From the user's perspective,
addAliasis just another name for the same function.DanTup commentedon Jun 9, 2026
It looks like the JS/TS tooling might capture the parameter names along with the type even though they're not part of the type. This can lead to inconsistencies, for example:
Here, the signature help is showing the wrong names compared to the function that would be called. It's a contrived example, but shows why it might not be sound to do this (at least for non-const variables).
dzylikecode commentedon Jun 9, 2026
Could this behavior be limited to
constbindings?For non-const variables, I agree that highlighting
var funcas a variable is useful because it signals that the binding can be reassigned. But forconst func = someFunction;, the binding cannot change, so from the user's perspective it behaves no differently from the function itself. Highlighting it as a plain variable feels more confusing to me than highlighting it like the function it refers to.bwilkerson commentedon Jun 9, 2026
The analyzer doesn't retain enough information for us to be able to display the names of positional parameters when all we have is a function type. I don't think it keeps enough information even in the case of a
constvariable.As a work-around, you could consider using named parameters, such as
DanTup commentedon Jul 2, 2026
Is it likely this would ever change? I don't know the scale of the work or whether if there are any other benefits to doing so. If not, I'll close this.
bwilkerson commentedon Jul 7, 2026
I doubt it, but we could double check on the sdk repo.
Because the names aren't used in any type-based operations (equality, subtype, etc.) keeping them wouldn't add any value to the analyzer, but would increase the amount of memory used. Some function types do point to a declaration from which they were derived, but using that information when it's available would lead to an inconsistent experience, so it isn't clearly the right solution.
DanTup commentedon Jul 9, 2026
I've opened dart-lang/sdk#63792 for discussion (I also included some notes about testing I did - it seems like Signature Help is already showing the parameter names in the cases I could come up with to test).
DanTup commentedon Sep 10, 2026
Fixed in dart-lang/sdk@5237fae
The change is in the analysis server so will ship in a future SDK release (not a Dart-Code release).