Date: Tue, 07 Jan 2025 08:32:00 -0600
On Sat, Jan 4, 2025, at 09:11, Simon Schröder via Std-Proposals wrote:
> Hi,
>
> Its my first time on this mailing list and I also don’t have any
> experience with the standardization process. Any help is welcome.
TLDR: if you are willing to work full time on this you can at best get it for C++32, but C++38 is more realistic.
I was hoping someone else would reply as they know more than me. Your have outlined a complex and interesting idea. However ideas are the easy part. What is needed is someone to do the hard complex work of proving the idea works in the real world (we were burned by export which seemed like a great idea but in the real world didn't work.) For your idea you need working code so we can evaluate it. That means writing the library you want so we can see how it works, possibly modifying a compiler (clang is most commonly used for this) to provide a working example. Then show that this library can be used in the real world - take some multi-million line codebase and show how you can add borrow checking to a small part without cascading errors until you everyone gives up. (const correct used to be a big deal - it took decades to get older cost bases const correct, if we are a looking at the same decades until this is adoptable in the real world we at least need to know going in - this may or may not itself be enough to say no we won't standardize this)
We cannot get your std::borrow into c++29, while the papers are easy enough to write, they point to a larger feature and you will need to show that the entire feature actually will come in the future and also that those things are useful stand alone. And the existence of the std2 means we need a debate about which way forward to go. That debate will take some time - often when one side brings up an objection the other will go "just give me some time" and a couple months later they will have solved (or mitigated) that objection. My quick read is the std2 the better way, and thus what I would want if this was 1980 (that is well before the current STL), but given all the millions of lines of C++ that use the STL today I'm worried that nobody could adopt it in any existing code base (again, a quick read so I reserve the right to change my mind).
I don't want to discourage you. C++ needs to do better. and your ideas are on a good track. However getting anything needs smart people to put in a lot of effort. Profiles seem to me something we can get for C++29, but they also appear limited. Various forms of borrow checking look like they might be a much better option, but they also need a lot more effort to get in (if they go in - I reserve the right say no based on something unknown today). At this point I want to encourage everyone with an idea to implement and present it so we can try it with real world code to see if it can be used.
> Hi,
>
> Its my first time on this mailing list and I also don’t have any
> experience with the standardization process. Any help is welcome.
TLDR: if you are willing to work full time on this you can at best get it for C++32, but C++38 is more realistic.
I was hoping someone else would reply as they know more than me. Your have outlined a complex and interesting idea. However ideas are the easy part. What is needed is someone to do the hard complex work of proving the idea works in the real world (we were burned by export which seemed like a great idea but in the real world didn't work.) For your idea you need working code so we can evaluate it. That means writing the library you want so we can see how it works, possibly modifying a compiler (clang is most commonly used for this) to provide a working example. Then show that this library can be used in the real world - take some multi-million line codebase and show how you can add borrow checking to a small part without cascading errors until you everyone gives up. (const correct used to be a big deal - it took decades to get older cost bases const correct, if we are a looking at the same decades until this is adoptable in the real world we at least need to know going in - this may or may not itself be enough to say no we won't standardize this)
We cannot get your std::borrow into c++29, while the papers are easy enough to write, they point to a larger feature and you will need to show that the entire feature actually will come in the future and also that those things are useful stand alone. And the existence of the std2 means we need a debate about which way forward to go. That debate will take some time - often when one side brings up an objection the other will go "just give me some time" and a couple months later they will have solved (or mitigated) that objection. My quick read is the std2 the better way, and thus what I would want if this was 1980 (that is well before the current STL), but given all the millions of lines of C++ that use the STL today I'm worried that nobody could adopt it in any existing code base (again, a quick read so I reserve the right to change my mind).
I don't want to discourage you. C++ needs to do better. and your ideas are on a good track. However getting anything needs smart people to put in a lot of effort. Profiles seem to me something we can get for C++29, but they also appear limited. Various forms of borrow checking look like they might be a much better option, but they also need a lot more effort to get in (if they go in - I reserve the right say no based on something unknown today). At this point I want to encourage everyone with an idea to implement and present it so we can try it with real world code to see if it can be used.
Received on 2025-01-07 14:32:27