Improve editor guidance for XGo's implicit expression-to-closure conversions

[aofei]

Problem

Some spx APIs accept a zero-argument callback because they need to evaluate an expression repeatedly. For example, waitUntil expects a condition of type func() bool.

XGo allows users to pass an expression directly:

waitUntil v.IsMature()

The compiler implicitly converts the expression into a closure, approximately equivalent to:

waitUntil => v.IsMature()

This conversion is not visible in the source code. XBuilder currently shows only the parameter-name inlay hint:

waitUntil condition: v.IsMature()

The condition: hint identifies the parameter, but it does not explain that the expression becomes a callback and may be evaluated multiple times.

A particularly confusing case is:

waitUntil v.IsMature

A user may write this accidentally after omitting (), but the code still compiles because v.IsMature is already a method value of type func() bool. It does not use the implicit expression-to-closure conversion.

Both forms are valid, but they rely on different language behavior. The editor currently provides no guidance about this distinction.

Possible improvement

Could xgolsw provide a dedicated inlay hint when XGo performs an implicit expression-to-closure conversion?

For example:

waitUntil condition: => v.IsMature()

Both condition: and => would be virtual editor hints.

The => hint could provide a tooltip such as:

XGo implicitly converts this expression to func() bool. waitUntil evaluates it each time it checks the condition.

The standard LSP textDocument/inlayHint capability appears suitable for this. An optional text edit could also allow users to make the conversion explicit by inserting => .

The hint should be based on resolved types rather than hard-coded API names.

Expected behavior:

• waitUntil v.IsMature() shows the implicit-conversion hint
• waitUntil ready shows the implicit-conversion hint
• waitUntil => v.IsMature() does not show a redundant hint
• waitUntil v.IsMature does not show the hint because it is already a method value
• Existing function values do not show the hint
• Valid method values are not reported as missing-parentheses errors

XBuilder may need to preserve and render the additional inlay hint and its tooltip when returned by xgolsw.

The waitUntil API documentation and teaching examples could also prefer the explicit form when introducing this behavior:

waitUntil => v.IsMature()

The goal is to make this non-obvious XGo conversion discoverable without treating valid code as an error or warning.

[aofei]

After further discussion, I no longer think displaying a virtual => is the right default solution.

The current syntax has an intentional teaching benefit:

waitUntil count == 0

repeatUntil count == 0, => {
    ...
}

The first argument reads naturally as a condition, while => {} remains associated with event handlers and executable bodies. Adding a virtual => before the condition would weaken this distinction and make repeatUntil look like it takes two lambdas.

A better direction may be declaration-side autoclosure metadata, modeled after Swift's @autoclosure.

The feature should apply to zero-argument functions with any result type:

func() T

It should not be specific to func() bool.

One possible Go-facing encoding, following existing __xgo_* parameter-name conventions, could be:

func WaitUntil(__xgo_autoclosure_condition func() bool)
func RepeatUntil(__xgo_autoclosure_condition func() bool, body func())

The exact encoding and native XGo syntax can be decided separately. This should be declaration metadata rather than a standard-library wrapper type or runtime decorator.

For an annotated func() T parameter:

• The source-level argument is type-checked as T
• The compiler then wraps the expression in func() T
• Explicit lambdas and existing function values are not accepted unless T itself is a function type
• Existing implicit expression-to-closure conversions for unannotated parameters remain unchanged

This gives the intended behavior:

waitUntil v.IsMature()    // Valid: the bool expression is wrapped
waitUntil v.IsMature      // Error: this is func() bool, not bool
waitUntil => v.IsMature() // Error for an annotated autoclosure parameter

It also preserves the desired repeatUntil form:

repeatUntil count == 0, => {
    ...
}

If existing projects rely on explicit lambdas for these APIs, XGo could temporarily accept them with a migration diagnostic and a code action that removes =>. This should be a compatibility measure rather than permanent autoclosure semantics.

Once this metadata is preserved through import and type checking, xgolsw could provide targeted editor guidance without inserting virtual syntax:

• Explain delayed evaluation in signature help or hover information
• Add an explanatory tooltip to the existing condition: inlay hint
• Diagnose likely missing parentheses for annotated parameters
• Offer a code action to call the function

The autoclosure metadata should only indicate deferred evaluation. Whether the expression is evaluated zero, once, or repeatedly remains part of the API contract and should be documented by APIs such as waitUntil.

This would preserve the child-friendly syntax while making the distinction between deferred expressions and callbacks explicit to XGo, xgolsw, and XBuilder.