On Mon, 2 Jan 2023 at 00:51, Tom Honermann via Lib-Ext
<lib-ext_at_[hidden]> wrote:
>
> Happy New Year!
>
> Jeff Garland recently indicated that he is intending to restart work on std::environment; an improved facility for interaction with environment variables. The following describes relevant history that I'm aware of and my own thoughts and preferences for a future proposal.
>
> History
>
> Previous discussions have been in the context of these two papers:
>
> P1275: Desert Sessions: Improving hostile environment interactions
> P1750: A Proposal to Add Process Management to the C++ Standard Library
>
> Records of previous discussion are available at the links below. Relevant std::environment related design polls are included inline (other polls are omitted but can be found in the linked records of discussion).
>
> 2018-11-07, San Diego, LEWGI discussion of P1275.
>
> POLL: std::environment should be immutable
> Attendance: 11
> SF
> F
> N
> A
> SA
> 4
> 4
> 1
> 1
> 1

This poll defeats the purpose of the facility. If I'll get a portable
replacement for getenv(), I shouldn't need to use putenv() either any
more. We should expose the capabilities of the system-specific
facilities we wrap into a portable API, not hide them behind
idealistic
APIs that don't allow something like setting an environment variable.
The environment is already global mutable state, and it's not
the job of std::environment to pretend otherwise, if you ask me. This
poll is also suggesting that we leave room for a language underneath
C++ here, and we shouldn't do that, in principle.