Please don’t take os.File as justification, it’s one of the few uses of a finaliser in the std lib. If it were being written today I would argue that instead of silently closing the file, it should panic if the resource falls out of scope unclosed.
As always, remember that finalisers are not guaranteed to run as they are tied to the gc cycle. In a well tuned application a finaliser can easily be delayed until the resource they are meant to mediate has been exhausted by overconsumption. Dave -- 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. For more options, visit https://groups.google.com/d/optout.
