Feedback from the Gripes and Wishes Campaign (page 7)

On Monday, 29 May 2023 at 05:20:24 UTC, Walter Bright wrote:

On 5/28/2023 2:39 AM, Paolo Invernizzi wrote:

Some news on that point?

The update is nobody has been willing to invest the time into it.

Sorry, that's not right. The status, as I understand it, is that stdV2 was not opened for people to invest their time in it. The stdV2 MR is still open. I think it should get in, no matter how unfinished, in a way that doesn't affect stdV1. It isn't feasible to work on stdV2 while it's base still exists only on Andrei's Phobos fork. If it's on Phobos codebase though, anyone can contribute as easily as to stable Phobos (in fact it's even easier since we don't have to worry about breaking V2 user code yet).

As I understand it, he complained that his PR messed up the docs somehow and as such could not be merged as-is.

On 30/05/2023 3:47 AM, Paul Backus wrote: > IMO the best way to make progress on stdv2 at this point is to create a dub package and start committing code. No need to wait for official approval. Unfortunately there are two quite big things that are more than a year away that it should be built from the ground up with. - Shared library support - Some other exception mechanism If you start now, there will still be breaking changes to come, which may not be worth somebodies time to do another evaluation & partial rewrite for. I'm super not looking forward to having to do this for my own stuff. Just the recent fixes for some DIP1000 type stuff is going to be a pain to go back and rewrite (although needed). Just something to consider.

On Monday, 29 May 2023 at 16:36:20 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 30/05/2023 3:47 AM, Paul Backus wrote: > Unfortunately there are two quite big things that are more than a year away that it should be built from the ground up with. > > - Shared library support > - Some other exception mechanism > > If you start now, there will still be breaking changes to come, which may not be worth somebodies time to do another evaluation & partial rewrite for. I'm not sure what it would mean for stdv2 to be built "from the ground up with" shared library support, especially given that code like ranges and algorithms will necessarily be implemented as templates and distributed as source code. I agree that it's worth revisiting the use of exceptions in the standard library (e.g., there's a lot of code that could be @nogc/BetterC compatible if not for exceptions), but I don't think it's a good idea to sit on our hands waiting for a speculative language feature that may never actually materialize. Worst case, if and when this new mechanism lands, we can start work on stdv3.

May 29, 2023

Re: Feedback from the Gripes and Wishes Campaign

Posted by Stefan Koch
in reply to Steven Schveighoffer

Permalink

Stefan Koch

Posted in reply to Steven Schveighoffer

Permalink

On Monday, 29 May 2023 at 18:10:08 UTC, Steven Schveighoffer wrote:

On 5/29/23 1:18 AM, Walter Bright wrote:

I tried to do that at one point, and failed, after spending a couple weeks on it. It's not impossible, it's just that our CTFE implementation is a rat's nest and defies such improvements.

It sounds like we need to revisit how CTFE is implemented. This should be a priority for D.

> >

If malloc allocates GC memory, wouldn't the GC just take care of it?

Then you might as well just use the GC instead of malloc.

The point is to make functions that currently use malloc CTFE-able, not to rewrite those functions so they are CTFE-able.

It's not as easy as I have said, but I think it's still doable.

-Steve

That can't actually happen while malloc is being malloc.
If we can rewrite the implementation it is possible but it means we have to special case malloc and treat it as a built-in function.

On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote: > revisiting the use of exceptions in the standard library As far as I'm concerned, they really shouldn't be used. I think exceptions are one of the worst features of C++, Java and D etc

On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti via Digitalmars-d wrote: > On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote: > > revisiting the use of exceptions in the standard library > > As far as I'm concerned, they really shouldn't be used. I think exceptions are one of the worst features of C++, Java and D etc Care to elaborate why? T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy

On Monday, 29 May 2023 at 20:57:22 UTC, H. S. Teoh wrote: > On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti via Digitalmars-d wrote: >> On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote: >> > revisiting the use of exceptions in the standard library >> >> As far as I'm concerned, they really shouldn't be used. I think exceptions are one of the worst features of C++, Java and D etc > > Care to elaborate why? > > > T Mainly because exceptions are often used for errors that aren't really exceptional", I often found myself having to handle exceptions (mostly in Java and C++) that really didn't give a damn and just abort the program. I have rarely seen exceptions handled well by programmers other than in C++ code done by really experienced programmers, I much prefer error handling like Rust and Go ie with multi-value returns, in my experience I have always found this technique leads to much better error handling than using exceptions. (https://go.dev/doc/faq#exceptions, https://go.dev/blog/error-handling-and-go, https://doc.rust-lang.org/book/ch09-00-error-handling.html)

On 5/29/23 4:11 PM, Stefan Koch wrote: > That can't actually happen while malloc is being malloc. > If we can rewrite the implementation it is possible but it means we have to special case malloc and treat it as a built-in function. Exactly what I'm saying... malloc should be interpreted by CTFE to be a special call to the CTFE allocator. -Steve

Forums