proposal: add shape package to stdlib for holding gcshape instance types

[randall77]

I'd like to reserve the shape stdlib package to hold compiler-generated gcshape types. Right those types live in the .shape package so it won't conflict with any real package name. But that makes generated code look ugly, in particular the leading dot gets escaped to %2e so there's a smattering of those escapes throughout the generated code for generics.

In addition, if we reserve the shape package it gives us a place to put some documentation, so that when someone disassembles their code and sees references to a shape package, they can find documentation on what that means.

Related: #37641

[mvdan]

I think this is a subset of #32819. Assuming we document that restriction during the freeze, then this proposal will already be de facto accepted and implemented :)

[rsc]

We've used go.string for a long time for string data. Can we use go.shape instead of reserving 'shape'?
I've never seen go%2estring - I'm not sure if it's a special case or not, but if so we could special case go.shape too.

[rsc]

I don't believe this is a subset of #32819 btw. #32819 says no one else can use 'shape'. But we might still have a use for a standard library package named 'shape' in the future, and continuing to use 'go.' for our internal symbols seems cleaner than cutting out real names.

[mvdan]

That's a fair point - I wasn't aware that go. as a prefix had a precedent.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[randall77]

Withdrawn - looks like go.shape should work.

[rsc]

This proposal has been declined as retracted.
— rsc for the proposal review group