Skip to content

Improve hover/completion for function-valued aliases (tear-offs) #6081

Closed

Description

@dzylikecode

Description

When a function is exposed as a top-level alias via a tear-off:

const InitWindow = 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
Image Image
void InitWindow(
  int width,
  int height,
  String title,
)

shows:

void InitWindow(
  int width,
  int height,
  String title,
)

with parameter names.

But hovering over:

const InitWindow = 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.

const InitWindow = proxy.InitWindow;

is much more concise than:

void InitWindow(
  int width,
  int height,
  String title,
) => proxy.InitWindow(width, height, title);

Activity

  1. added
    is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.
    on Jun 9, 2026
  2. FMorschel commented on Jun 9, 2026

    @FMorschel
    Contributor
  3. DanTup commented on Jun 9, 2026

    @DanTup
    Member

    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:

    var InitWindow = 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.

    While it might be possible to look up the value for a const variable, 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".

  4. dzylikecode commented on Jun 9, 2026

    @dzylikecode
    Author

    Could we take JavaScript's behavior as a reference here? addAlias is present as a function instead of a variable.

    Image

    From the user's perspective, addAlias is just another name for the same function.

  5. DanTup commented on Jun 9, 2026

    @DanTup
    Member

    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:

    Image

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

  6. dzylikecode commented on Jun 9, 2026

    @dzylikecode
    Author

    Could this behavior be limited to const bindings?

    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.

  7. bwilkerson commented on Jun 9, 2026

    @bwilkerson

    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

    void InitWindow({required int width, required int height, required String title}) {}
  8. DanTup commented on Jul 2, 2026

    @DanTup
    Member

    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.

  9. bwilkerson commented on Jul 7, 2026

    @bwilkerson

    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.

  10. DanTup commented on Jul 9, 2026

    @DanTup
    Member

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

  11. added this to the v3.140.0 milestone on Jul 9, 2026
  12. modified the milestones: v3.140.0, v3.142.0 on Jul 28, 2026
  13. added
    relies on sdk changesSomething that requires changes in the Dart/Flutter SDK to ship before it will become available
    in lsp/analysis serverSomething to be fixed in the Dart analysis server
    and removed on Aug 26, 2026
  14. modified the milestones: v3.142.0, v3.144.0 on Sep 1, 2026
  15. self-assigned this
    on Sep 9, 2026
  16. DanTup commented on Sep 10, 2026

    @DanTup
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

in lsp/analysis serverSomething to be fixed in the Dart analysis serveris enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.relies on sdk changesSomething that requires changes in the Dart/Flutter SDK to ship before it will become available

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions