Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Go] Known limitations related to Go 1.18 #3512

Open
mitranim opened this issue Oct 27, 2022 · 1 comment
Open

[Go] Known limitations related to Go 1.18 #3512

mitranim opened this issue Oct 27, 2022 · 1 comment
Assignees
Labels
C: Syntax T: bug A bug in an existing language feature

Comments

@mitranim
Copy link
Contributor

mitranim commented Oct 27, 2022

Adapted from #3289 (comment).

  • In parameter lists, type instantiations (type name followed by type argument list in square brackets) should be scoped as types.
    • Actual: type instantiations are scoped as parameters.
interface{Method(Type[TypeArg])}

func(Type, Type[TypeArg])
  • In interfaces, when embedding an interface expressed as a type instantiation (interface name followed by type argument list in square brackets), type arguments should be scoped as variable.other.type.
    • Actual: type arguments are scoped as variable.other.
interface{EmbeddedInterface[TypeArg]}
  • "Function call" detection should work with type arguments of arbitrary complexity, rather than just with identifiers.
    • Actual: function call detection doesn't work when the list of type arguments passed to a function contains complex type expressions such as type instantiations.
FuncName[Type[TypeArg]]()
  • Parameter lists should support types of arbitrary complexity such as [][]Ident.
    • Actual: some parameter types such as [][]Ident are not scoped as types.
func FuncName(param [][]Type)
  • In calls to namespaced functions or methods (which are syntactically identical), when there is a list of multiple type parameters separated by commas, type arguments should be scoped as variable.other.type.
    • Actual: type arguments are scoped as variable.parameter.type.
namespace.FuncName[TypeArg, TypeArg]()
  • Calls to type-instantiated functions (func name followed by list of type arguments in square brackets) should be recognized as function calls even when the function name is namespaced.
    • Actual: function instantiations are recognized as function calls only when function names are not namespaced.
namespace.FuncName[TypeArg]()
@mitranim mitranim added the T: bug A bug in an existing language feature label Oct 27, 2022
@f9x0
Copy link

f9x0 commented Jun 15, 2024

Please, whoever can, do this.
I really miss these things!

deathaxe added a commit to deathaxe/sublime-packages that referenced this issue Sep 25, 2024
Addresses some issues described in sublimehq#3512 with least effort.

It may not address all theoretical edge cases though.

Especially meta scopes don't follow guidelines by any means, so seriously
fixing issues would probably end up in significant refactoring, which is not
scope of this commit/PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Syntax T: bug A bug in an existing language feature
Projects
None yet
Development

No branches or pull requests

3 participants