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: strconv: add Not #37836

Open
carnott-snap opened this issue Mar 13, 2020 · 3 comments
Open

proposal: strconv: add Not #37836

carnott-snap opened this issue Mar 13, 2020 · 3 comments
Labels
Milestone

Comments

@carnott-snap
Copy link

@carnott-snap carnott-snap commented Mar 13, 2020

I find myself writing this function (or code snippet) far too frequently, one possible option is to implement a turnery function, but that has been turned down before. Assuming this too has not been declined, could some flavour be added to strconv:

func Not(b bool) string {
        if b {
                return "not "
        }
        return ""
}

I am quite amenable to other names, and there may be a better way to support other languages or functionality:

func When(b bool, s string) string {
        if b {
                return s
        }
        return ""
}
@gopherbot gopherbot added this to the Proposal milestone Mar 13, 2020
@gopherbot gopherbot added the Proposal label Mar 13, 2020
@mvdan
Copy link
Member

@mvdan mvdan commented Mar 15, 2020

A lot of people are giving a thumbs down, so I'll try to give a reason behind mine.

This seems like a trivial amount of code and logic for a new piece of API. I understand you wanted more powerful syntax instead, but that being rejected doens't mean that we should fall back to adding multiple "single line" functions to the standard library.

If you personally find such a function useful, I think it's reasonable to add it to your package. After all, it's just five lines :)

@carnott-snap
Copy link
Author

@carnott-snap carnott-snap commented Mar 15, 2020

My question would be where should this logic live:

  • stdlib: community seems to say no
  • inline: too complex
  • library: if Go gets a guava, boost, or other third party standard library, I think that is endemic of a large problem and community fragmentation.
  • module: should I need to reimplement this for every module?

At the end of the day, I do not care about this specific function, but think the core problem is worth tackling.

@arnottcr
Copy link

@arnottcr arnottcr commented Apr 21, 2020

Requesting inclusion in #33502.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.