x/tools/gopls: Postfix complete supports ordinary functions

[rogeryk]

gopls version

14.2

go env

unimportant

What did you do?

unimportant

What did you expect to see?

Now gopls already support postfix complete, which is very useful in some scenarios, but these all provides pre-defined.
Some completion is just some ordinary functions.

• for string：split, join
• for slice: len, append

In fact, we do not need to pre-define these functions, just need to search for all the first parameter types according to the type of X in X.Sel, and then match the name of Sel.
For example, the following program s, all functions in strings should appear in completion.

var s string
s.|    // complete: HasSuffix, Split, ContainsRune, ...

This feature is useful for some basic types, such as string, slice, map. There are also places to pack different implement using functions, such as Context.Context types.

For some types, these completions may cause disturb, so it should have a relatively low priority.

What did you see instead?

unimportant

Editor and settings

No response

Logs

No response

[muirdm]

Interesting idea. This might make more sense outside postfix snippets since it involves searching for matching candidates. It's also a less-bounded search than the normal search of object methods, so we would probably have to limit the search scope somehow.

[findleyr]

Interesting. Whenever I want to use something from the strings package, I start by typing strings.. Why is it desirable to start with the argument and complete "backwards"?

[rogeryk]

Let me explain in detail why：

• First of all it is a style, I think some functions should be treated as methods, cause some built-in types or types in other packages cannot add methods. So it makes sense to complete them like methods. In c#, kotlin, swift, they have "extension function" to solve this.
• It will allow you to type less and have a better experience. If you forward input, you need to type "pkgName", "funcName", "varName". In backward complete, you need to "varName", "funcName". And it doesn't go against your intuition, as mentioned earlier, some functions should be treated as methods.
• And It's not just a matter of hitting a few keys. In many projects I work on there are many packages like "strutil", "timeutil", "sliceutil", sometimes you can't be sure which package a function is in.
• Postfix completion has some additional advantages when modifying code, for example. Like the code below, the return of someFunction is a string. Now I wish to remove the spaces on both sides (strings.TrimSpace)，I had to move the cursor to the front, type, and then move the cursor to the back to complete the brackets. But in postfix completion, you just have to keep the cursor behind and complete.

a := someFunction()

[findleyr]

@rogeryk thanks for the explanation. It's an interesting idea, but definitely not trivial, and I'm not sure it is worth it. We will reconsider when we cross-prioritize feature requests.

[rogeryk]

@findleyr From a comparison of the difficulty of implementation and the benefits, it does seem a bit mismatched. The main reason for this idea is that I feel after implementation, users will no longer need to customize suffixes. Currently, there is no support for users to customize suffix completion. Are there any plans for this?