On Fri, Jan 31, 2020 at 10:33 AM Craig Rodrigues <crodr...@gmail.com> wrote: > > > On Friday, January 31, 2020 at 7:23:32 AM UTC-8, Ian Lance Taylor wrote: >> >> >> Calling flag.Parse in an init function never worked reliably, unless >> you took special care. Flags are themselves often defined in init >> functions, so calling flag.Parse in an init function will see the >> flags that were defined before the point of the call but not the flags >> defined after the point of the call. I guess it was working for you, >> but small changes in your code could have caused it to stop working. >> We didn't document that calling flags.Parse in an init function didn't >> work reliably because we didn't realize that anybody would ever do it. >> The documentation always just said "After all flags are defined, call >> flag.Parse", and "Must be called after all flags are defined and >> before flags are accessed by the program" without spelling out that if >> you call it in an init function you won't necessarily be calling it >> after all flags are defined. >> >> The change to the testing package changed exactly when the testing >> flags are defined with respect to init functions, and it caused many >> cases of calling flag.Parse from an init function to break. But those >> cases were already fragile and could have been broken in other ways >> also. >> >> If you don't call flag.Parse from an init function you will be >> following the documentation, and that will continue to work. >> >> Sorry for the trouble. >> > > > > Thanks for the response. I have a few questions. > > 1. In https://golang.org/pkg/flag/#Parse , would it be appropriate to add a > warning to not call this function from inside init()? > This was not obvious to me from reading the docs.
Documentation should normally be precise and not overly long. I personally don't feel that an explicit comment about calling flag.Parse from an init function carries its weight. The documentation is already clear that you must only call Parse after defining all flags, and as noted previously you have limited control over initialization order. I think that more useful would be to implement https://golang.org/issue/33190 (contributions welcome). > 2. To fix my problem, I removed flag.Parse() completely. Is that the > appropriate fix? Where would it be appropriate for me > to call flag.Parse()? Or should I never bother calling it (inside test > files)? It's not necessary to call flag.Parse in a test. The test harness will call it for you. It's OK to call flag.Parse from a TestMain function, and in fact that is required if TestMain is going to change its behavior based on a flag (this is documented at https://golang.org/pkg/testing/#hdr-Main). Broadly speaking, the only other place that Go code should call flag.Parse is in the main function, though of course there can be specific reasons to call it from other places. > 3. Is calling flag.Parse() from inside https://golang.org/pkg/testing/#Init > supposed to work? I tried that and it also did not work. That is a function in the standard library, so I'm not sure what you are asking. Are you changing the standard library? There shouldn't be a need to do that in order to parse flags. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWvo_tnv3e5Rq_nX8Njsn36hyjD_eY3SNOU7uV9qugW%3DQ%40mail.gmail.com.
