The use of panic with a "TODO" message is not suitable for production code. This should be replaced with proper error handling that provides a clear compile-time error to the user. The current logic doesn't handle variadic functions without non-variadic parameters (e.g., func(...T)), leading to a panic. This case should be handled gracefully, for instance, by disallowing keyword arguments for such functions.

Using panic with a "TODO" message for unhandled cases is not robust. It should be replaced with proper error handling that reports a clear compile-time error, indicating which types are supported for keyword argument merging.

The calculation of the Rbrace position for the generated CompositeLit as kwargs[n-1].End() - 1 is likely incorrect. The End() method on an AST node typically returns the position after the node, so subtracting 1 would point to the last character of the last keyword argument's value. A more correct position for the closing brace would be kwargs[n-1].End(), representing the position immediately after the keyword arguments. This ensures better source mapping for tools that consume this AST.

The calculation of the Rbrace position for the generated CompositeLit as kwargs[n-1].End() - 1 is likely incorrect. The End() method on an AST node typically returns the position after the node, so subtracting 1 would point to the last character of the last keyword argument's value. A more correct position for the closing brace would be kwargs[n-1].End(), representing the position immediately after the keyword arguments. This ensures better source mapping for tools that consume this AST.

Critical: Inadequate error handling

Replace this TODO panic with a descriptive error message:

This provides better context for debugging and matches the codebase's error reporting pattern.

Critical: Missing validation before merge

fn.arg(n, false) can return nil when n exceeds the valid parameter range (see line 611). This will cause mergeKwargs to panic with a generic error. Add validation:

High: Improve error message with type information

Include the actual type encountered to help debugging:

Also consider using ctx.newCodeErrorf if position information is available from the kwargs.

Security: Add bounds checking

Accessing kwargs[0] and kwargs[n-1] without validating the slice is non-empty could cause a panic. While the caller currently checks len(v.Kwargs) > 0, add defensive validation:

Same issue exists in mergeStructKwargs at line 785.

Documentation: Add function documentation

This is a key function for the kwargs feature. Please add a doc comment:

Documentation: Add algorithm overview

The kwargs transformation logic is complex, especially for variadic functions. Add a comment explaining the overall approach:

Documentation: Explain field resolution behavior

Add documentation for this important function that handles Python-style naming conventions:

Replace panic with descriptive error message:

return ctx.newCodeErrorf(v.Pos(), v.End(), 
    "keyword arguments require at least %d positional arguments before variadic parameter, got %d", 
    idx, len(v.Args))

Issue: The current generic panic "TODO: no kwargs or arguments not enough" makes debugging extremely difficult. Users need to know:

1. Which function call failed
2. How many arguments were expected
3. How many were provided

Using ctx.newCodeErrorf provides position information and clear guidance.

Replace panic with specific error message:

return ctx.newCodeErrorf(kwargs[0].Pos(), kwargs[len(kwargs)-1].End(),
    "keyword arguments require parameter type to be struct, *struct, or map[string]T, got %v", t)

Issue: The current "TODO: unexpected kwargs type" doesn't tell users:

• What type was encountered
• What types work with kwargs

This improved message clearly states the supported types and shows what was actually provided.

Add comprehensive comment explaining the kwargs transformation algorithm:

// Transform kwargs into composite literal arguments based on parameter type.
// For variadic functions: kwargs are inserted before the variadic parameter position.
// For non-variadic functions: kwargs are appended as an additional argument.
// The mergeKwargs function handles type-specific transformations (struct/map).
// https://github.com/goplus/xgo/issues/2443
if len(v.Kwargs) > 0 {
    // ... existing code
}

Issue: The current code only has a GitHub issue reference but doesn't explain:

1. Why variadic and non-variadic functions are handled differently
2. What the insertion strategy is
3. What mergeKwargs does

This documentation is critical for future maintainers to understand the algorithm and edge cases.

Add function documentation:

// mergeKwargs converts keyword arguments into an appropriate composite literal
// based on the target parameter type:
//   - struct or *struct: creates a struct literal with field names (via mergeStructKwargs)
//   - map[string]T: creates a map literal with string keys (via mergeStringMapKwargs)
// Returns a CompositeLit expression that can be used as a regular function argument.
func mergeKwargs(kwargs []*ast.KwargExpr, t types.Type) ast.Expr {

Issue: The function lacks documentation explaining what it does and how it decides which merge strategy to use. This is a key function in the kwargs implementation and needs clear documentation for maintainability.

Add function documentation with example:

// mergeStringMapKwargs converts keyword arguments into a map[string]T composite literal.
// Each kwarg name becomes a string key in the resulting map literal.
// Example: foo(a: 1, b: 2) becomes foo(map[string]int{"a": 1, "b": 2})
func mergeStringMapKwargs(kwargs []*ast.KwargExpr) ast.Expr {

Issue: This function has no documentation explaining the transformation. An example helps clarify the behavior.

Add comprehensive documentation for field name resolution:

// getFldName resolves a kwarg identifier to the actual struct field name.
// It handles three cases:
//   1. Exact match: kwarg name matches struct field name exactly
//   2. Capitalization match: unexported kwarg name matches exported field when capitalized
//      (e.g., "cache" matches "Cache", allowing Python-style lowercase kwargs)
//   3. Fallback: returns original name if no match (type checker will report error later)
func getFldName(name *ast.Ident, t *types.Struct) *ast.Ident {

Issue: This function implements important field name resolution logic that allows Python-style lowercase kwargs to map to Go's exported field conventions. Without documentation, the capitalization behavior is mysterious and could cause confusion.

The documentation explains all three cases and the fallback strategy, making the code maintainable and the behavior predictable.