On Saturday, 10 January 2026 11:09:26 Brasilia Standard Time Jody Hagins via
Std-Proposals wrote:
> The implicit lifetime type requirement isn't academic. It's essential for:
>
> - **Shared memory** — inter-process communication via memory-mapped regions
> - **Memory-mapped files** — persistent data structures
> - **Custom allocators** — placement new into raw storage
> - **`std::start_lifetime_as`** — explicit lifetime management

Memory-mapped files and shared memory are the same thing: shared memory is
implemented by memory-mapping a shared file. The only difference is that we call
"memory mapped file" when your sharable data isn't being shared with any other
process.

So my 2¢, which may be an unpopular opinion:

- for newly allocated memory (new mmapping of anonymous memory, brk(), custom
allocators, etc,) you can and should just do a placement new or
std::construct_at(). The stumbles on the problem of being able to call this
memory storage region a "byte array" where no array had previously existed,
but that can be solved as a much more restricted problem than for any
implicit-lifetime type.

- for shared memory (which includes memory-mapped files with content), the
lifetime *had* *already* *started* before you did the mmaping. You've just
made it visible to the application. Therefore, you should have no business
using std::start_lifetime_as, std::launder or any such thing. The compilers
and abstract machine need to be adapted to know the lifetime had started, not
have programmers work around to declaring such.

A corner case is when one read()s a file/socket/pipe/whatever. I'd mostly argue
that this is a byte array and one can successfully reconstruct the integers
and strings that comprise such without resorting to start_lifetime_as either.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.