Go Programming Experience

Experienced

Other Languages Experience

Go, C++, TypeScript, PHP, JAVA

Related Idea

  • [X] Has this idea, or one like it, been proposed before?
  • [X] Does this affect error handling?
  • [X] Is this about generics?
  • [X] Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

No

Does this affect error handling?

No

Is this about generics?

No

Proposal

Currently, when calling functions from another package in Go, there are two main approaches: Using var FunctionName = otherPackage.FunctionName, Or using func FunctionName with linkname. While the first approach is more aligned with Go's design principles, it can be unsafe and may lead to unexpected behavior.

To address this issue, we propose a safer approach that leverages Go's type system to ensure type safety and better aligns with Go's design principles. The proposed approach is to use the following syntax to call functions from another package:

func FunctionName = otherPackage.FunctionName

This approach ensures that the function being called is of the correct type and provides a more explicit and safer way to call functions from another package.

Justification The proposed approach has several benefits:

Type Safety: By using the func keyword, we ensure that the function being called is of the correct type and avoids potential.

Better Alignment with Go's Design Principles: The proposed approach aligns with Go's design principles by providing a more explicit and safer way to call functions from another package.

Improved Readability: The proposed approach provides a clearer and more explicit way to call functions from another package, improving code readability and maintainability.

Language Spec Changes

No response

Informal Change

No response

Is this change backward compatible?

Yes, The proposed change to use func FunctionName = otherPackage.FunctionName for calling functions from another package in Go is backward compatible. This syntax enhancement does not break existing code or introduce any breaking changes. It simply provides a more explicit and safer way to call functions, ensuring type safety and alignment with Go's design principles without affecting the compatibility with existing codebases. Developers can choose to adopt this new syntax in their code while still maintaining compatibility with older Go code that uses the traditional method of calling functions from another package.

Orthogonality: How does this change interact or overlap with existing features?

No response

Would this change make Go easier or harder to learn, and why?

Easier to Learn: Simplicity: The proposed syntax is straightforward and easy to understand. It clearly indicates the intent of calling a function from another package without the risk of unintended modifications. Consistency: By aligning with Go's design principles and providing a more explicit way to call functions, the proposed change promotes consistency and clarity in code, which can aid in the learning process for beginners. Safety: The emphasis on type safety and avoiding potential type mismatches with the proposed syntax can help new developers write more robust and error-free code from the beginning.

Potential Challenges: Learning Curve: While the new syntax is designed to enhance safety and clarity, it may initially pose a learning curve for developers accustomed to the existing method of calling functions in Go. Transition Period: Existing developers may need time to adjust to the new syntax, especially if they have been using the traditional method for a long time. This transition period could potentially add complexity during the learning process. In conclusion, while the proposed change may introduce some initial challenges, the emphasis on clarity, safety, and alignment with Go's design principles could ultimately make the language easier to learn and use, especially for newcomers looking to write reliable and maintainable code in Go.

Cost Description

No response

Changes to Go ToolChain

No response

Performance Costs

No response

Prototype

No response

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: mateusz834

Why not directly call the function, like:

func FunctionName() {
    otherPackage.FunctionName()
}

Comment From: godcong

@mateusz834 This approach has several pain points. 1. not flexible enough, if the function changes in other packages, you need to manually change the function you call 2. not concise enough, you need to define a function, and then call the function in other packages 3. not intuitive enough, it looks like a function, but in fact it is actually calling a function in another package

So more often than not, var FunctionName = otherPackage.FunctionName is used. Some global variables that can't be defined by const are at risk of being accidentally changed, not only functions, but also initial values defined by var, but it's more complicated with variables... Because there is no readonly.

There are many uses of linkname in Go. But I don't want to make heavy use of linkname in my packages

Perhaps using

const var FunctionName = otherPackage.FunctionName

would be a good solution. This would also work for global variables.

Comment From: seankhliao

Duplicate of #58897