Hi Thiago.

Thanks for the input.

I don't really disagree with anything you wrote.

I included both shared memory and memory mapped files mainly because different operating systems may have completely different views of things. In particular, I know absolutely nothing about windows except that I'm always told "except on windows" and since I've never really used windows, and never write code that is expected to run on windows, I gave up caring a long time ago.

However, the standard must care about windows, and I didn't want to make any assumptions.

I, too, wish there was no need for is_implicit_lifetime and that it all just worked by magic.

Unfortunately, I think that ship has sailed.

I certainly don't have the time nor the energy for such an endeavor. I'm a pretty decently experienced user, but as for defining what the compiler implementors can or should be able to do, that is way out of my league.



> On Jan 11, 2026, at 11:30 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals