These look desirable, especially when interacting with low-level system APIs.
Is it okay to bake the stack vs heap limit into executables?
The names are what they are; they derive directly from our existing naming scheme for these sorts of constructs. FWIW, I find top-level with… functions are both undiscoverable (when I need them) and are too much in my face (when I don’t), at the same time. I think I’d prefer if we moved these as static functions under their corresponding types, like @benrimmington suggested during the pitch:
UnsafeMutableBufferPointer<Foo>.withEphemeral(capacity: 42) { buffer in … }
UnsafeMutableRawBufferPointer.withEphemeral(byteCount: 42, alignment: 8) { buffer in }
UnsafeMutablePointer<Foo>.withEphemeral { pointer in … }
The new functions are a good thematic fit with the existing allocate members, and tucking these away in the preexisting unsafe types would reduce concerns about adding even more top-level unsafe constructs to the stdlib.