On Monday, October 30, 2023 1:48:46 AM MDT Sergey via Digitalmars-d wrote:
> On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis
>
> wrote:
> > 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
>
> Hi Jonathan.
> The author of the topic came to D from C#. And in the C# they
> have this feature. On of the example is to check the status of
> the tasks - if it was successfully finished, canceled, killed by
> exception.
> Some simple example can be found here:
> https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstat
> us?view=net-7.0

Thanks for the info.

Task in std.parallelism already provides the done property to ask whether a task has been completed (be it successfully or by an exception being thrown). It does not provide any way to cancel tasks, and the functions on Task which deal with actually making it do anything are largely variations on getting the result (be it by getting it because it's already ready, by waiting for it to be completed, or by actually forcing the task to be done on the current thread to get the result). As such, there does not appear to be anything useful which can be done based on the task status except based on whether it's done or not - which Task already provides.

So, with the API that std.parallelism provides, actually making the TaskStatus public does not appear to have any useful purpose, and by its very nature, the answer stands a decent chance of being out-of-date, because once the TaskStatus is outside of the Task, it's just information on what the status was when it was synchronized from the thread that it was on, not information on what the actual, current status is. So, acting on that information risks introducing race conditions (assuming that you can actually do anything with that information), and if you can't actually do anything with that information (and std.parallelism doesn't seem to make it so that you can), then there's no point in exposing it.

It might make sense to expose the TaskStatus with a different API (which C# obviously has if it's going to allow things like canceling tasks), but no one has provided a good reason for why it should be exposed in std.parallelism beyond the done property which already exists. And sadly, Imperatorn has repeatedly decided to get mad with us rather than engage in a technical discussion on why exposing the task's status beyond having the done property would actually be a good idea. It's quite possible that there is something that we are missing, and exposing the TaskStatus actually makes sense, but there need to be technical reasons for that, and none have been presented.

- Jonathan M Davis

Sometimes, if we knew what problem you're faced with, we can find the best solution. Help us help you!

On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:
> On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis wrote:
>> [...]
>
> Because it would be wonderful. I could use it to draw a rainbow on the screen.

This attitude won't help you.

On Monday, 30 October 2023 at 17:47:33 UTC, Patrick Schluter wrote:
> On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:
>> On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis wrote:
>>> [...]
>>
>> Because it would be wonderful. I could use it to draw a rainbow on the screen.
>
> This attitude won't help you.

Sure, but neither does not trying to understand a basic use case used by millions in C# already.

It's like asking why would you need printf, just use the debugger.

Sure, but sometimes printf can be kinda useful.

If you're not even *trying* to understand, how does it help anyone?

In a way it's a kind of "anti-help", since not only was no help given, but it also reduces the probability anyone with a similar use case will get help in the future.

If there was a "helpfulness-metric", it would decrease every time someone would ask a good question and get an "anti-help" answer.

So, over time, fewer questions would get asked, and of course if that happens it's kinda hard to answer them after a while, since it would reach zero.

Just because someone doesn't understand a use case doesn't mean millions of people are idiots, it might mean you simply don't see the value that those millions of people do, and therefore you don't understand it.

You just have to ask what is more likely.

On Monday, 30 October 2023 at 17:27:27 UTC, Walter Bright wrote:
> Sometimes, if we knew what problem you're faced with, we can find the best solution. Help us help you!

That's good to hear. Since D will be running on at least 50 thousand devices within a year, it's kind of important.

It will be a very small project, that's why I feel confident. Just some things that are lacking, but no big deal, we can work around them.

We have compared 20 languages before coming to D, Nim, Go and C++ included. Our analysis showed that even though D is a smaller language, its learning curve is not steep and if you don't do weird stuff, the code is comprehensible and maintainable.

I have already put 3 packages on dub just to accomodate some missing features. dub works well and supports cross-compilation, which has been very easy to do for us.

Both from x64 Windows to aarch64 Linux and from x64 Linux to x64 Windows.

D is easy to learn, yet powerful, while also being efficient.

For example, take a look at the benchmark I, schveiguy and Sergi took part in:
https://github.com/jinyus/related_post_gen

We hope that D will continue to flourish and that we will be able to use it in the future