I'm sure this has been discussed many times before - perhaps more around the desire for
constructors - but I couldn't find any obvious proposals with Go2/LanguageChange tags so
if this is a dupe, my apologies.

I don't have any proposed syntax or tightly defined semantics, this is more about what
people think of the idea.

Proposal

Simply put, the proposal is to be able to attach a formal Destructor (in Java-speak, a
Finalizer) to a type. This should be something that the type can explicitly define without
participation by users of that type.

The motivation is to be able to garbage collect resources invisible to the go GC and not
have to rely on packages users to "do the right thing". Such resources include
process-based resources such as file descriptors and sockets as well as external resources
such as disk files. Any non-go resource really.

Rationale

While go isn't particularly designed to directly manipulate underlying OS resources the
way one might do in lower-level languages, there are still many occasions when a go
program does directly create OS resources which it wants to actively destroy.

Examples within go include os.File, http.Body and the net.*Conn family. Essentially any
type which offers a Close() call.

Examples outside of go include file system objects such as cache files, named pipes and
.lock files used to signal other applications via the file system.

More obscure examples include OS resources created by the likes of dup(), Dup2() and
Flock() out of the https://godoc.org/golang.org/x/sys/unix package.

Any package which creates these sort of resources usually wants to offer a way to destroy
them at the end of their life-cycle. This is what Destructors traditionally do in other
languages.

Why not Close() as the defacto Destructor?

The obvious counter to introducing a formal Destructor is that go already has an idiomatic
Destructor in the form of Close(). So what's wrong with continuing with this approach?

Lots of things frankly. First off, it's a bit antithetical as go programmers are not
well-conditioned to worrying about resource cleanup due to the GC nature of go and
corresponding lack of formal constructors. In other words, we've spent the last decade
training go programmers to code like this:

   import "packageX"

   func do() {
     x := packageX.Stuff{}
     x.Do()
   }

which means they aren't particularly on the lookout for formal Constructors/Destructors
yet alone informal Destructors like Close() in packages they import. Nor are they
conditioned to adding Close() in any package they create.

One could even argue that the absence of formal Destructors encourages ephemeral system
resource usage within packages. Is that always a good thing? I doubt it.

Secondly, it's not intuitive which packages need a Close() and which don't. I was
surprised to find that net.Resolver doesn't have a Close() whereas the popular
https://github.com/miekg/dns Client exposes a Conn which does require a Close(). Clearly
the net DNS resolver doesn't cache UDP sockets whereas the miekg/dns resolver
can. Intuitive much?

Perhaps an even better example of counter-intuitive uses of Close() is the http package. I
don't know how many times I've tried to remind myself of http.Body.Close() because in the
back of my mind I know there is some weird Close() when one would never expect it. It
doesn't help that there is a Server.Close(), a Body.Close(), but no Client.Close(),
Request.Close() or Response.Close(). To an outside observer this non-symmetric, random
smattering of Close() calls must be quite confusing. To me Body.Close() is just too easy
to overlook since I rarely code http clients.

Third, if a package initially ships without Close() but a later version requires one -
perhaps because the author has determined resource caching offers substantial performance
improvements - they can't do so transparently without risking resource leaks. Sure they
could introduce a pseudo-constructor, such as:

      resolver := package.NewWithClose()

but this means that no existing importers automatically benefit from the package
enhancements. They all have to change application code first.

This can be a cascading problem of course: If package A imports package B which
subsequently introduces B.NewWithClose() and B.Close(), then A is forced to introduce
an A.NewWithClose() and A.Close() so applications can reach down to the
B.Close(). That seems pretty ugly to me.

The only way to avoid this retrofit problem is for package designers to have perfect
foresight to know if they or any other contributor will ever require a Close() at any time
in the future of their package or its imports. Reductio ad absurdum leads us to the
conclusion that every package type should offer a Close() even if they are mostly noops.

Summary

I don't think the whole "Close() as a proxy for explicit Destructors" is working very well
as idioms go and it likely stifles package evolution as one cannot transparently retrofit
Close() semantics.

Clearly with the presence of Close() in many packages and interfaces, there is demand for
Destructors, so why not formalise Destructors and eliminate our imperfect Close() idiom?

As a bonus, if we have formal Destructors, we can simplify the interface surface of many
packages. Just looking at the "io" package: we could get rid of Closer, ReadCloser,
WriteCloser and ReadWriteCloser.

Complications

I admit that I don't know the complexities of implementing formal Destructors into the go
runtime yet alone determining the exact semantics. E.g., when should the Destructor be
called? When the instances go out of scope? When the GC cleans them up? Or do we invent a
special Destructor goroutine that reads a channel of types ready for destruction?
Dunno. Obviously if it's extremely difficult then that has some sway on the idea.

PS. Inexperienced with the proper submission protocol for proposals.