C++ Logo


Advanced search

Re: [isocpp-lib-ext] std::environment

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Mon, 2 Jan 2023 01:20:12 +0200
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
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.

Received on 2023-01-01 23:20:25