ISOCPP std-proposals List: by date

To subscribe or unsubscribe to this list (or change your subscription options), see the list information page.

Friday, 26 June 2026

Re: [std-proposals] A better std::byte type Rainer Deyke
Re: [std-proposals] A better std::byte type Rainer Deyke
Re: [std-proposals] A better std::byte type Zhihao Yuan
Re: [std-proposals] A better std::byte type Alejandro Colomar
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Alejandro Colomar
Re: [std-proposals] A better std::byte type Thiago Macieira
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Bjorn Reese
Re: [std-proposals] A better std::byte type Alejandro Colomar
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Sebastian Wittmeier
Re: [std-proposals] A better std::byte type Rune Lund Olesen
Re: [std-proposals] A better std::byte type Alejandro Colomar
Re: [std-proposals] A better std::byte type David Brown
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Jan Schultke
Re: [std-proposals] A better std::byte type Rune Lund Olesen

Thursday, 25 June 2026

Re: [std-proposals] A better std::byte type Thiago Macieira
Re: [std-proposals] A better std::byte type Alejandro Colomar
Re: [std-proposals] A better std::byte type Andre Kostur
Re: [std-proposals] A better std::byte type Andrey Semashev
Re: [std-proposals] A better std::byte type Jan Schultke
Re: [std-proposals] A better std::byte type Jan Schultke
Re: [std-proposals] A better std::byte type Tiago Freire
Re: [std-proposals] A better std::byte type Jonathan Wakely
Re: [std-proposals] A better std::byte type Rainer Deyke
[std-proposals] A better std::byte type Rune Lund Olesen

Wednesday, 24 June 2026

Re: [std-proposals] Preprocessor multi-line macroes Jens Maurer
Re: [std-proposals] Preprocessor multi-line macroes Alejandro Colomar
Re: [std-proposals] Preprocessor multi-line macroes Alejandro Colomar
Re: [std-proposals] Preprocessor multi-line macroes Thiago Macieira
Re: [std-proposals] Preprocessor multi-line macroes Halalaluyafail3
Re: [std-proposals] Preprocessor multi-line macroes Jens Maurer
[std-proposals] Preprocessor multi-line macroes Frederick Virchanza Gotham
Re: [std-proposals] D4285R0 Floating-point traits Jens Maurer
Re: [std-proposals] D4285R0 Floating-point traits Tiago Freire
Re: [std-proposals] D4285R0 Floating-point traits Sebastian Wittmeier
Re: [std-proposals] D4285R0 Floating-point traits Jan Schultke

Tuesday, 23 June 2026

Re: [std-proposals] D4285R0 Floating-point traits Tiago Freire
Re: [std-proposals] D4285R0 Floating-point traits Jens Maurer
Re: [std-proposals] D4285R0 Floating-point traits Halalaluyafail3
[std-proposals] D4285R0 Floating-point traits Jan Schultke

Monday, 22 June 2026

Sunday, 21 June 2026

Re: [std-proposals] Translation-unit-local functions that access private class fields Máté Ték
Re: [std-proposals] Translation-unit-local functions that access private class fields Steve Weinrich
Re: [std-proposals] Translation-unit-local functions that access private class fields Arthur O'Dwyer
Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
Re: [std-proposals] Allow using type alias in requires-clause Arthur O'Dwyer
Re: [std-proposals] Translation-unit-local functions that access private class fields Rhidian De Wit
Re: [std-proposals] Huge Hello World Jonathan Wakely
Re: [std-proposals] Huge Hello World Bo Persson
Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
[std-proposals] Huge Hello World amngis_21d38
Re: [std-proposals] Translation-unit-local functions that access private class fields Simon Schröder
Re: [std-proposals] Big integers Sebastian Wittmeier
Re: [std-proposals] Big integers Jens Maurer
Re: [std-proposals] Big integers Jan Schultke
[std-proposals] Big integers amngis_21d38
[std-proposals] Big integer amngis_21d38
Re: [std-proposals] Translation-unit-local functions that access private class fields Sebastian Wittmeier
Re: [std-proposals] Translation-unit-local functions that access private class fields Simon Schröder
Re: [std-proposals] Allow using type alias in requires-clause Jens Maurer
Re: [std-proposals] Allow using type alias in requires-clause Hewill Kang
Re: [std-proposals] [[assume_assert(expr)]] and/or evaluation semantics mode "assume". Jonathan Grant

Saturday, 20 June 2026

Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
Re: [std-proposals] Translation-unit-local functions that access private class fields Rhidian De Wit
Re: [std-proposals] Allow using type alias in requires-clause Jens Maurer
Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
Re: [std-proposals] Translation-unit-local functions that access private class fields Thiago Macieira
Re: [std-proposals] Allow using type alias in requires-clause Hewill Kang
Re: [std-proposals] Entity concept Sebastian Wittmeier
Re: [std-proposals] Old Strings Proposal Jens Maurer
Re: [std-proposals] Translation-unit-local functions that access private class fields Sebastian Wittmeier

Friday, 19 June 2026

Re: [std-proposals] Entity concept Ville Voutilainen
[std-proposals] Entity concept amngis_21d38
Re: [std-proposals] Translation-unit-local functions that access private class fields Steve Weinrich
Re: [std-proposals] Translation-unit-local functions that access private class fields Sebastian Wittmeier
Re: [std-proposals] Translation-unit-local functions that access private class fields weinrich.steve_at_[hidden]
Re: [std-proposals] Old Strings Proposal Jan Schultke
[std-proposals] Old Strings Proposal Rhidian De Wit
Re: [std-proposals] Translation-unit-local functions that access private class fields Rhidian De Wit
Re: [std-proposals] Translation-unit-local functions that access private class fields Sebastian Wittmeier
Re: [std-proposals] Translation-unit-local functions that access private class fields Rhidian De Wit
Re: [std-proposals] Don't use templates for differentiating Lvalues from Rvalues Rhidian De Wit
Re: [std-proposals] Don't use templates for differentiating Lvalues from Rvalues Jan Schultke
[std-proposals] Don't use templates for differentiating Lvalues from Rvalues Frederick Virchanza Gotham

Wednesday, 17 June 2026

Re: [std-proposals] Direct-list-initialization syntax for default function arguments Simon Schröder

Tuesday, 16 June 2026

Re: [std-proposals] Direct-list-initialization syntax for default function arguments Bo Persson
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Ungureanu Radu
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Alejandro Colomar
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Ungureanu Radu
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Sebastian Wittmeier
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Alejandro Colomar
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Sebastian Wittmeier
Re: [std-proposals] Direct-list-initialization syntax for default function arguments Ungureanu Radu

Monday, 15 June 2026

Re: [std-proposals] Direct-list-initialization syntax for default function arguments Halalaluyafail3
[std-proposals] Direct-list-initialization syntax for default function arguments Radu Ungureanu
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Frederick Virchanza Gotham

Friday, 12 June 2026

Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Dr.ThomasCatalano

Wednesday, 10 June 2026

Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Frederick Virchanza Gotham
Re: [std-proposals] Float the idea: First-class effect annotations ..(Sebastian Wittmeier, Thiago Macieira, Rainer Deyke) Michael Galuszka

Tuesday, 9 June 2026

Re: [std-proposals] Float the idea: First-class effect.. Michael Galuszka
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Sebastian Wittmeier
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Rainer Deyke
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Thiago Macieira
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Sebastian Wittmeier
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Rainer Deyke

Monday, 8 June 2026

Re: [std-proposals] Float the idea: First-class effect.. Thiago Macieira
Re: [std-proposals] Std-Proposals Digest, Vol 87, Issue 24 Michael Galuszka
Re: [std-proposals] Float the idea: First-class effect.. Michael Galuszka
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Thiago Macieira
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Thiago Macieira
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Arthur O'Dwyer
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Sebastian Wittmeier
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Sebastian Wittmeier
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Alejandro Colomar
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Frederick Virchanza Gotham
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Frederick Virchanza Gotham
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Bjorn Reese
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Jonathan Grant
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ David Brown
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Alejandro Colomar

Sunday, 7 June 2026

Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Sebastian Wittmeier
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Sebastian Wittmeier
Re: [std-proposals] Achieving pragma pack(1) with typedef<unaligned> Andre Kostur
[std-proposals] Achieving pragma pack(1) with typedef<unaligned> Frederick Virchanza Gotham
Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Ville Voutilainen
[std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ Michael Galuszka
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Rainer Deyke
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Giuseppe D'Angelo
Re: [std-proposals] equal_range on unordered associative containers Giuseppe D'Angelo
Re: [std-proposals] equal_range on unordered associative containers Rainer Deyke
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Sebastian Wittmeier
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Rainer Deyke
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Jonathan Wakely
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Howard Hinnant

Saturday, 6 June 2026

Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Sebastian Wittmeier
Re: [std-proposals] equal_range on unordered associative containers Giuseppe D'Angelo
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Rainer Deyke
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Jonathan Grant
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Thiago Macieira
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Tiago Freire
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Sebastian Wittmeier
Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate Steve Weinrich
[std-proposals] Exceptions : lost all hope -- do not resuscitate Frederick Virchanza Gotham
Re: [std-proposals] equal_range on unordered associative containers Bjorn Reese
Re: [std-proposals] equal_range on unordered associative containers Mital Ashok
Re: [std-proposals] equal_range on unordered associative containers Keenan Horrigan

Friday, 5 June 2026

Re: [std-proposals] equal_range on unordered associative containers Rainer Deyke
Re: [std-proposals] equal_range on unordered associative containers Thiago Macieira
Re: [std-proposals] equal_range on unordered associative containers Hewill Kang
Re: [std-proposals] equal_range on unordered associative containers Rainer Deyke
Re: [std-proposals] equal_range on unordered associative containers Rainer Deyke
Re: [std-proposals] equal_range on unordered associative containers Hewill Kang
Re: [std-proposals] equal_range on unordered associative containers Mital Ashok
[std-proposals] equal_range on unordered associative containers Rainer Deyke

Wednesday, 3 June 2026

Re: [std-proposals] Function-bound objects with unary operator % Frederick Virchanza Gotham
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Petr Nechaev
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Jonathan Grant
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Jason McKesson
Re: [std-proposals] What a non-reallocating version of the standard would look like. Thiago Macieira
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Tiago Freire
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Giuseppe D'Angelo
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Jan Schultke
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Rainer Deyke

Tuesday, 2 June 2026

Re: [std-proposals] What a non-reallocating version of the standard would look like. Jonathan Grant
Re: [std-proposals] What a non-reallocating version of the standard would look like. Jonathan Grant
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Jens Maurer
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Adrian Johnston
Re: [std-proposals] What a non-reallocating version of the standard would look like. Adrian Johnston
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Lénárd Szolnoki
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Sebastian Wittmeier
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Alejandro Colomar
Re: [std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Steve Weinrich
[std-proposals] Strategic Direction for AI in C++: Governance, and Ecosystem Adrian Johnston
Re: [std-proposals] What a non-reallocating version of the standard would look like. Sebastian Wittmeier
Re: [std-proposals] What a non-reallocating version of the standard would look like. Tiago Freire
Re: [std-proposals] Function-bound objects with unary operator % Jonathan Wakely
Re: [std-proposals] std::flat_map and bool keys/values Aryan Naraghi
Re: [std-proposals] Function-bound objects with unary operator % Adrian Johnston
Re: [std-proposals] Function-bound objects with unary operator % Andre Kostur
Re: [std-proposals] Function-bound objects with unary operator % Mital Ashok
Re: [std-proposals] Function-bound objects with unary operator % Thiago Macieira
Re: [std-proposals] What a non-reallocating version of the standard would look like. Adrian Johnston

Monday, 1 June 2026

Re: [std-proposals] Function-bound objects with unary operator % Frederick Virchanza Gotham
Re: [std-proposals] Function-bound objects with unary operator % Zhihao Yuan
Re: [std-proposals] Function-bound objects with unary operator % Sebastian Wittmeier
Re: [std-proposals] Function-bound objects with unary operator % Zhihao Yuan
Re: [std-proposals] Function-bound objects with unary operator % Sebastian Wittmeier
Re: [std-proposals] Function-bound objects with unary operator % Mital Ashok
Re: [std-proposals] Function-bound objects with unary operator % Thiago Macieira
Re: [std-proposals] Function-bound objects with unary operator % Sebastian Wittmeier
[std-proposals] Function-bound objects with unary operator % Frederick Virchanza Gotham
Re: [std-proposals] What a non-reallocating version of the standard would look like. Jonathan Grant
Re: [std-proposals] What a non-reallocating version of the standard would look like. Jonathan Wakely
Re: [std-proposals] What a non-reallocating version of the standard would look like. Adrian Johnston

Last message date: 2026-06-26 22:48:59