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

proposal: all : ternary operators in golang #60502

Closed
pacifiquem opened this issue May 30, 2023 · 5 comments
Closed

proposal: all : ternary operators in golang #60502

pacifiquem opened this issue May 30, 2023 · 5 comments
Labels
Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@pacifiquem
Copy link

Title: Proposal for the Addition of Ternary Operators in Go

Introduction:
The purpose of this proposal is to advocate for the inclusion of ternary operators in the Go programming language. Ternary operators provide a concise and expressive way to handle conditional expressions, which can improve code readability and maintainability. This proposal aims to outline the benefits, address potential concerns, and present a design proposal for the implementation of ternary operators in Go.

Benefits:
2.1. Readability and Expressiveness:
Ternary operators enable developers to express simple conditional statements in a more concise and natural manner. By providing a compact syntax, they can reduce the cognitive load on programmers and enhance code readability. This is especially valuable for straightforward conditionals that do not require complex control flow structures.

2.2. Reduced Boilerplate Code:
Ternary operators eliminate the need for repetitive if-else blocks, resulting in reduced boilerplate code. This not only enhances code clarity but also reduces the chances of introducing bugs due to incorrect bracket placement or missing else statements.

2.3. Familiarity:
Ternary operators are widely used in many popular programming languages such as C, C++, Java, and Python. Their inclusion in Go would make the language more familiar and accessible to developers who are accustomed to working with these operators in other languages. This can lead to increased adoption of Go among developers coming from other programming backgrounds.

Potential Concerns:
3.1. Complexity:
One concern that may arise is the potential increase in code complexity due to the misuse or abuse of ternary operators. However, the proposed ternary operators would be limited to simple expressions and not allow complex control flow. By imposing such restrictions, we can mitigate the risk of misuse and encourage responsible usage.
3.2. Maintainability:
The introduction of new language features always raises concerns about code maintainability. To address this, clear guidelines and best practices should be provided to ensure consistent usage and readability of ternary operators. Additionally, linters and code analysis tools could be enhanced to detect potential issues and suggest improvements related to ternary operator usage.

Design Proposal:
4.1. Syntax:
The proposed syntax for ternary operators in Go is as follows:

result := condition ? valueIfTrue : valueIfFalse

The ternary operator consists of three parts: the condition, the value to be assigned if the condition is true, and the value to be assigned if the condition is false.

4.2. Type Safety:
To maintain Go's strong static typing, both the "valueIfTrue" and "valueIfFalse" expressions must have compatible types. If the types are incompatible, a compilation error should be raised.

4.3. Evaluation Order:
The proposed ternary operator would strictly follow the left-to-right evaluation order. This ensures predictable behavior and avoids potential confusion.

Compatibility and Migration:
To ensure backward compatibility, existing Go code would not be affected by the introduction of ternary operators. This proposal aims to introduce a new language feature without breaking existing code or altering the behavior of the Go programming language.

Conclusion:
The addition of ternary operators in Go would bring numerous benefits, such as improved code readability, reduced boilerplate code, and increased familiarity for developers coming from other programming backgrounds. By addressing potential concerns through clear guidelines, best practices, and tooling enhancements, we can ensure responsible usage and maintainability. We believe that the proposed ternary operators will enhance the Go programming experience and make the language more expressive and efficient.

Please consider this proposal for the inclusion of ternary operators in Go, as it would be a valuable addition to the language's syntax and functionality.

Thank you for your time and consideration.

@gopherbot gopherbot added this to the Proposal milestone May 30, 2023
@bitfield
Copy link

Please read the discussions on previous (rejected) ternary operator proposals, such as #33171, and see the FAQ entry that explains why they were (and will be) rejected: https://go.dev/doc/faq#Does_Go_have_a_ternary_form

@pacifiquem
Copy link
Author

@bitfield
While it is acknowledged that Go's designers deliberately omitted the ternary operator in favor of using if-else statements for clarity, could the inclusion of ternary operators be considered as an optional feature, given their potential benefits in terms of code readability, expressiveness, and familiarity with other languages? Are there any alternative approaches that could address concerns about code complexity while still allowing developers the choice to utilize ternary operators in situations where they enhance code conciseness and maintainability?

@pacifiquem
Copy link
Author

Also considering that proposals for the inclusion of ternary operators in Go have been consistently raised every year since 2016, indicating a persistent demand from the developer community, would the Go maintainers be open to reevaluating the possibility of introducing ternary operators? Could this recurring interest be seen as a strong indication that developers perceive a genuine need for ternary operators in Go to improve code readability and simplify expressions, while still maintaining the language's emphasis on clarity and simplicity?

@mvdan
Copy link
Member

mvdan commented May 30, 2023

Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

@mvdan mvdan added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 30, 2023
@ianlancetaylor
Copy link
Contributor

Thanks for the proposal, but there is no new information here that is not in previously rejected proposals such as #33171. We can reconsider past decisions when there is new information, but we can't continually revisit past decisions when nothing has changed. We must be able to decide and move on.

Closing this proposal. Sorry.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale May 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

5 participants