What current, real world, problem does this proposal address?

Hi Dave,
thanks for the prompt response. Sorry, for the late response.
Take e.g. Javascript: Douglas Grockford spent time identifying the “good parts of JavaScript”—for PayPal. He should not have needed to write a whole tool (JSLint) that checks code for “bad parts”.

Go not being JavaScript, let me take Mat Ryer’s “Things in Go I never Use” (speech at GothamGo 2018). Companies may decide which “not good for us parts”. They lack tool enforcement for non-usage of bad parts. Tools like JSLint cannot restore the lost productivity.

“Bad libraries” are an even greater challenge “Bad” may mean because they contain other “bad parts” or non-technical properties It may be because of attached risks with regard to maintenance assurance, licensing issues etc. Tool support is needed for libraries as well.

I hope this added some clarity.
Thanks for considering
Eugene

Thank you for your reply. This still feels rather subjective. Can you give some examples of specific features, packages, or api calls which should be disallowed? Personally I’d like to see runtime.SetFinalizer banished.

Right. Even objectively people come to different conclusions due to e.g. differences in expertise degree and background, operational context, tasks to solve, … I accept that and want to deal with it. Esp. given that GO does not throw the maximum features to the world trying to make everybody happy. Providing some room and mechanisms for additional and differentiated minimization to those who know best about the concrete GO usage deserves at least a consideration. The proposal is such it is thereby not needed to know, care or agree on what is reduced in each instance.

As a prominent example occurring in each company take the dichotomy between needs of infrastructure vs. application builders --each company practically does both. Let take a few features:
• Labels, fallthrough, goto …: Most likely no one would have missed them
• Panic, error and reflect packages: Infrastructure builders need them. In applications with human interaction just using the error package would be a violation of I18N and L12N standards. As BIZ application vendor you want them enforced. Panic in end user messages would be banned as well as too rude to end users. Application developers would need and be required to use libraries of higher abstraction level and greater convenience under the impossibility to use reflect.
• Generally speaking, as a company you don’t necessarily want features and libraries always banned., but specifically per environment assigned a clear usage.

I know there is some advice, e.g. on how to do better with errors than just the error package (Dave Cheny, Steve Francia,…,) or why not unnecessarily toying with e.g. the reflect package (Rob Pike ...). Some technical built-in assistance, not built-around the JSLint style, should at least be considered.

What’s wrong with the reflection package? It’s going to be pretty hard to do json decoding or print a formatted string without it?

Re: panic. If you remove panic from the language what should happen if a slice out of bounds condition occurs? Can that still panic)

• application developer would use panic only indirectly, i.e. through a library that itself uses reflect.
• I don't want panic to be removed. The runtime should panic. Not application developers. They should always recover and terminate the application more nicely and meaningful info the end user can act upon

To me this sounds like a proposal that is better implemented by a third party rather than the core Go team.

fair enough

Update (esp. to Ian): Meanwhile I took a try. I was surprised how awesome go.token, go/types, go/ast, go/parser, go/printer et al. are: Putting the standardization aspect aside, I realized that GO already does an excellent job at enabling implementation of GO code introspection and transformation tool even beyond the requirements raised above. And that despite having written my first go code only a year ago. I am not new at programming though.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group