> On Jan 1, 2023, at 6:20 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> 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.

I agree.

Tom.