Comment 1:

the problem is that the user can't recover from oom situations, so really the only
reliable way is try not allocating too much.

Comment 2:

I don't agree -- I'd think there's a situation that user can gracefully handle OOM. For
example, in bytes/buffer.go, it recovers from a panic from make to return an ErrTooLarge
to user.

Comment 3:

that's entirely different thing.
you can recover from that case simply because there is a static check inside runtime for
unreasonable len/caps.
If the actual memory allocation fails,
the program will crash.
And I think that's implementation detail
that shouldn't be exposed, as they are
not reliable and only catches silly errors.
If we want to document it, just say if make
can't fulfill the request, it will panic,
and it might or might not be recoverable.

Comment 4:

I agree that in general OOM is not recoverable, but what's in my mind is the case when
user wants to do a similar thing as bytes.buffer does.

Comment 5:

but as I said, that only catches very silly errors like allocating a slice that's
bigger than the maximum heap size, and in that case, the user can easily
check the argument himself.
this kind of test is implementation detail, and I doubt we want to expose
to the user. (Because it can change at any time, and other Go implementations
might just blindly allocate the memory and crash, so the user can't even
rely on this behavior if he wants to write portable Go.)

Comment 6:

See also issue #7871.
By the way, it does not panic, it exits the program.

Status changed to WontFix.