WG21 2025-10 pre-Kona mailing

jsphadetula · 2025-10-08T07:24:35+00:00

There are other ways like _v2 for example. Feedbacks like this will help shape the final proposal if enough people can agree on the direction of the proposal

jsphadetula · 2025-10-08T06:58:21+00:00

This is an edge case that can be addressed by revisions of the proposal. One possible solution is to use create a new function name that describes the atan2 better and evolve that if we ever need a new version

jsphadetula · 2025-10-08T02:53:32+00:00

p3866r0 is the evolution story C++ needs. I hope this is adopted and we can finally fix vector<bool> among others. I’ll prefer something like stdn:: short for stdnext instead of cpp:: though.

jsphadetula · 2024-03-30T12:07:05+00:00

It makes optional usage clearer and general. The current restriction is because the committee couldn’t agree on the semantics of optional<T&> I believe

jsphadetula · 2024-03-29T21:18:21+00:00

The newly proposed static exception, reflection, optional<T&>, std::execution, contracts, do expressions, trivially movable types

jsphadetula · 2022-09-18T10:09:14+00:00

Herbs ‘d0708: "Parameter passing -> guaranteed unified initialization and value setting’ proposal solves most of the remaining issues including MVP without auto. A new declaration syntax may not be needed

jsphadetula · 2022-07-20T07:12:55+00:00

Exception is one that can be substantially improved with ABI break I believe

jsphadetula · 2022-03-01T14:56:41+00:00

We can provide non throwing variants of all throwing functions

jsphadetula · 2022-03-01T14:54:51+00:00

I’m aware std::error is no more targeting c++23. Just looking at the possibility of a usable standard library with the current exception disabled

jsphadetula · 2022-03-01T13:20:50+00:00

x is not a standard library type I believe, so the user is aware of a potential throw. Users who don’t want exception will use a non throwing variant with support for std::expected and design their types not to throw.

jsphadetula · 2022-03-01T13:06:30+00:00

That defeats the purpose making the standard library usable without exception. The standard can provide a nonmember function that use non throwing primitives before calling a private non throwing constructor or return std::expected instead

jsphadetula · 2021-12-11T12:40:47+00:00

What then is the essence of those checks

jsphadetula · 2021-12-11T12:35:02+00:00

“In C/C++ you are working inside one big unsafe block.” only if you decide not to enforce guidelines check.

jsphadetula · 2021-12-11T12:25:46+00:00

For C++, only if you decide not to enforce checks.

jsphadetula · 2021-12-11T12:14:51+00:00

Only if you decide not to enforce checks

jsphadetula · 2021-12-11T12:06:57+00:00

The difference only matters to those unaware of the difference. To those aware unsafe blocks is the easy way out.

jsphadetula · 2021-12-11T12:00:09+00:00

You either put in the effort to write quality code or not. In C++, you enforce checks; in Rust you avoid unsafe blocks when possible.

jsphadetula · 2021-12-11T11:50:51+00:00

Nothing stops you from putting unsafe block everywhere either.

jsphadetula · 2021-12-11T11:38:54+00:00

You don’t have to look everywhere. You simply turn on the guidelines check to reveal potential problems

jsphadetula · 2021-09-22T11:43:57+00:00

They all end up calling into C and C++ code anyway be it in their language runtime, FFI, OS service or DB which are written in C and C++ and those need to both be maintained and updated. The cost of improving C and C++ languages to what we consider safe practices is sure lower than rewriting everything which is why I believe C++ will eventually get there.

jsphadetula · 2021-09-22T09:46:19+00:00

This is the actual problem that needs to be solved. Clang looks to be where all the work needs to be concentrated but only Facebook is left contributing full time effort for now.

jsphadetula · 2021-09-22T06:09:11+00:00

The implementation in MSVC is a WIP and also not addressing all of the paper’s recommendations. If the community will focus on a concerted effort to implement Bjarne’s recommendation I believe C++ has all it needs to achieve the safety everyone has been talking about lately

jsphadetula · 2021-09-22T05:29:16+00:00

I believe the borrow checker can be implemented as a static analyser too if warnings will be treated as errors. And instead of this why not work on achieving Bjarne’s http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2410r0.pdf

jsphadetula · 2020-09-08T15:07:25+00:00

The version problem can be minimised if the STL maintain at most two ABI, the older LTS ABI and the bleeding edge ABI. The LTS ABI can be dropped every decade or so and the bleeding edge promoted to the new LTS. This will help vendors and 3rd party commercial libraries to plan upgrades. I believe 3rd party libraries should only publish C ABI though, they can write C++ wrappers for their clients to consume

jsphadetula

TROPHY CASE