On Sunday, 29 October 2023 at 18:20:28 UTC, Walter Bright wrote:
> On 10/29/2023 5:54 AM, Imperatorn wrote:
>> However, we are becoming unsure if D is really an option for us given the response we got trying to making almost the smallest change imaginable to phobos (changing a single word).
>
> What is that change?

Nevermind, it was just exposing the TaskStatus enum. But it turned out that the property taskStatus that contained the value for it was not supposed to be exposed either, and the AbstractTask was just a "temporary" fix back in 2011, and also taskStatus was being accessed by alias this.

A bug report has been created for it by schveiguy since I can't access bugzilla because of an intermittent DNS problem.

Next step is to provide a safe way to get the task status after the pr has been merged.

On 10/29/2023 11:38 AM, Imperatorn wrote:
> A bug report has been created for it by schveiguy since I can't access bugzilla because of an intermittent DNS problem.

And a PR:

https://github.com/dlang/phobos/pull/8834


> Next step is to provide a safe way to get the task status after the pr has been merged.

On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:
> On 10/29/2023 11:38 AM, Imperatorn wrote:
>> A bug report has been created for it by schveiguy since I can't access bugzilla because of an intermittent DNS problem.
>
> And a PR:
>
> https://github.com/dlang/phobos/pull/8834
>
>
>> Next step is to provide a safe way to get the task status after the pr has been merged.

Yes, it's great to see. Now the next step is to improve it so that you can get the task status safely 😎

On Sunday, October 29, 2023 3:03:00 PM MDT Imperatorn via Digitalmars-d wrote:
> On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:
> > On 10/29/2023 11:38 AM, Imperatorn wrote:
> >> A bug report has been created for it by schveiguy since I can't access bugzilla because of an intermittent DNS problem.
> >
> > And a PR:
> >
> > https://github.com/dlang/phobos/pull/8834
> >
> >> Next step is to provide a safe way to get the task status after the pr has been merged.
>
> Yes, it's great to see. Now the next step is to improve it so that you can get the task status safely 😎

You have yet to explain why that information should be made public. Even if you can get the task status without breaking thread-safety, the information is still likely to be out-of-date by the time you actually try to do anything based on it, because once you have the state information out of the Task, that state information is no longer synchronized across threads. It's just a copy of what the state was when the state was copied across threads. So, actually making it possible to get the state information in a thread-safe manner doesn't fix the problem that trying to do anything based on that information involves race conditions.

And none of the functions on the Task are designed in such a way that it really makes sense to call them or not based on whether a task has started or not. The design of std.parallelism very purposefully only exposed the status of whether the task is done or not, because that's really the only actionable state information with the set of functions that it provides.

In general, trying to do anything based on whether the task has started or not is going to be subject to race conditions unless what you're trying to do is actually built into the Task like the *Force functions are.

So, the question is what problem are you trying to solve by making the task status public? What does that enable that you cannot currently do without that information?

If you have a good use case, then it may make sense to expose the state information, but as was pointed out in your previous PR, exposing that state information is likely to mislead programmers and risk causing them to write code that has race conditions due to out-of-date state information - and no one reviewing the PR saw how exposing that state information would actually enable anything. So, please provide a use case where exposing that state information actually enables something that you can't do without it.

- Jonathan M Davis

On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis wrote:
> On Sunday, October 29, 2023 3:03:00 PM MDT Imperatorn via Digitalmars-d wrote:
>> [...]
>
> You have yet to explain why that information should be made public. Even if you can get the task status without breaking thread-safety, the information is still likely to be out-of-date by the time you actually try to do anything based on it, because once you have the state information out of the Task, that state information is no longer synchronized across threads. It's just a copy of what the state was when the state was copied across threads. So, actually making it possible to get the state information in a thread-safe manner doesn't fix the problem that trying to do anything based on that information involves race conditions.
>
> [...]

Because it would be wonderful. I could use it to draw a rainbow on the screen.