On Mon, 2 Jan 2023 at 01:20, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:

POLL: std::environment should be immutable

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 should perhaps add that there is existing practice, here:
https://doc.qt.io/qt-6/qtglobal.html#qputenv

I'm fully aware that qgetenv() and qEnvironmentVariable() have
different data-loss behaviors on different
platforms, so that part is a bit quirky to take as existing practice
to consider for standardization. :)

Thank you for those links. Reading the documentation for them reinforced my belief that programmers have a need to access raw environment variable values (as in qgetenv()), but without requiring conversion to char or byte-based storage (e.g., raw wchar_t access on Windows) and to access values as text (as in qEnvironmentVariable() via conversion to the associated encodings of char, wchar_t, char8_t, char16_t, and char32_t with the understanding that such conversion will be lossy in some cases). The design used for std::filesystem::path will suffice for both purposes with a minor tweak; we should provide separate interfaces for access to the raw data vs access as text so that the latter can provide valid encoding guarantees. For example, given an environment variable FOO with the value "a\xFF\xFFz" (four bytes long containing the values 'a', 0xFF, 0xFF, 'z') on a POSIX system using UTF-8 for the execution encoding and UTF-32 for the wide execution encoding, access of the value via the following member functions would yield results with the indicated type and value (where encoding conversion is from UTF-8 (the execution encoding) and follows Unicode PR-121 policy 1 for substitution of ill-formed code unit sequences; U+FFFD is the Unicode replacement character).

• raw() -> std::span<char> (std::span<wchar_t> on Windows) where the spanned range is "a\xFF\xFFz".
  
• string() -> std::string containing "a\uFFFDz" (UTF-8).
  
• wstring() -> std::wstring containing L"a\uFFFDz" (UTF-32).
  
• u8string() -> std::u8sstring containing u8"a\uFFFDz" (UTF-8).
  
• u16string() -> std::u16string containing u"a\uFFFDz" (UTF-16).
• u32string() -> std::u32string containing U"a\uFFFDz" (UTF-32).

This differs from (the intent of and existing practice for) std::filesystem::path as indicated by the notes in [fs.path.type.cvt]p2 that state that no conversion is performed when the access is for a type that matches the implementation-defined value_type.

Tom.