On Saturday, 6 June 2020 at 21:14:44 UTC, Steven Schveighoffer wrote:
> To continue the "show" analogy, consider a theater show where all the show light bulbs burn out simultaneously. You could say "Well, they can do it by flashlight," and yes, it could happen. People wouldn't be able to see it, but the show would *happen*. So one could argue that not having significant lighting is not a showstopper in the way you are saying "just use void initialization".

There are theatre works that are designed to be performed in total or near-total darkness :-)

On 6/6/2020 2:14 PM, Steven Schveighoffer wrote:
> To continue the "show" analogy, consider a theater show where all the show light bulbs burn out simultaneously. You could say "Well, they can do it by flashlight," and yes, it could happen. People wouldn't be able to see it, but the show would *happen*. So one could argue that not having significant lighting is not a showstopper in the way you are saying "just use void initialization".

On the other hand, how many shared local variables does one have in a program?

Every shared variable is a risk of threading problems, and one should try to minimize their use.

On 6/6/20 5:56 PM, Walter Bright wrote:
> On 6/6/2020 2:14 PM, Steven Schveighoffer wrote:
>> To continue the "show" analogy, consider a theater show where all the show light bulbs burn out simultaneously. You could say "Well, they can do it by flashlight," and yes, it could happen. People wouldn't be able to see it, but the show would *happen*. So one could argue that not having significant lighting is not a showstopper in the way you are saying "just use void initialization".
> 
> On the other hand, how many shared local variables does one have in a program?

I thought the intialization problem was in constructors for shareable items, not for local variables? In any case, this is bending an implementation deficiency into a "feature" of dissuasion. If something shouldn't be done, there are better ways to prevent it than requiring void initialization (which in itself is a dangerous thing to require).

> Every shared variable is a risk of threading problems, and one should try to minimize their use.

This is why the changes are great -- you have to write code that removes the shared qualifier to deal with actually using the data, under the guidance of the library which knows the semantic meaning of the data.

Wrapping this into a useful type is what the purpose is. But constructors generally have free reign to provide an initial value even for immutable data. I don't see why it should be different for shared (the point is that it's being constructed, so nothing has access to that item yet).

Maybe I'm misunderstanding the issues. If there's a way to make it so only a small amount of code has to use void initialization, and user code never has to do that, it might be workable (but I don't speak for Manu). But certainly that is still considered a bug, and not an intended feature, right?

-Steve

On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
> Oops, what about you?

It's all I know. shrug.

On Saturday, 6 June 2020 at 13:20:53 UTC, H. S. Teoh wrote:
> On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via Digitalmars-d wrote:
>> On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
>> > ... and, tragically, the reason for that is mostly because we wrote this thing in C++! I've been having a really un-fun time at work because I failed to make a pitch for D in the ~18 months window we had, and now I have to suffer that failure :(
>> 
>> I'm really curious, if you had those features (Shared for example) the
>> way you liked... you could pitched the company (Blizzard) to develop
>> games for videogames in D?
>> 
>> What about the GC? Wouldn't that be a bottleneck or it would be without GC?
>
> Wasn't Manu one of the people who pushed for @nogc and eventually got it in?

I dunno.

Matheus.

On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
> I thought the intialization problem was in constructors for shareable items, not for local variables? In any case, this is bending an implementation deficiency into a "feature" of dissuasion.

I said it was ugly, not a feature.

> But certainly that is still considered a bug, and not an intended feature, right?

I posted a PR to fix it. But it's still not a showstopper.

On 6/6/20 9:37 PM, Walter Bright wrote:
> On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
>> I thought the intialization problem was in constructors for shareable items, not for local variables? In any case, this is bending an implementation deficiency into a "feature" of dissuasion.
> 
> I said it was ugly, not a feature.

Good. Sometimes statements like "well you shouldn't be doing that anyway" can make things unclear what the expectation is.

> 
>> But certainly that is still considered a bug, and not an intended feature, right?
> 
> I posted a PR to fix it. But it's still not a showstopper.

Thanks.

-Steve

On Sunday, 7 June 2020 at 14:18:50 UTC, Steven Schveighoffer wrote:
> On 6/6/20 9:37 PM, Walter Bright wrote:
>> On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
>>> I thought the intialization problem was in constructors for shareable items, not for local variables? In any case, this is bending an implementation deficiency into a "feature" of dissuasion.
>> 
>> I said it was ugly, not a feature.
>
> Good. Sometimes statements like "well you shouldn't be doing that anyway" can make things unclear what the expectation is.
>
>> 
>>> But certainly that is still considered a bug, and not an intended feature, right?
>> 
>> I posted a PR to fix it. But it's still not a showstopper.
>
> Thanks.
>
> -Steve


This thread has a specific purpose. The purpose is those people using D in production or their project, why are they using it. So that others can find confidence and use it too. It is not a thread to argue about D problems. Let keep the focus of the thread. This one of the most beautiful thread I have enjoyed since my two years plus of being this forum. Move all other discussions to another thread pls.....

This thread if properly utilize or manage will be a great encouragement to a newbie in D tomorrow. I am really encouraged by D.

So we are waiting for more testimonies from happy users

On Saturday, 6 June 2020 at 07:00:57 UTC, Walter Bright wrote:
> On 6/5/2020 10:16 PM, Manu wrote:
>> Initialisation and `ref` emit errors?
>> They're absolutely show stoppers. Values must be initialised, and code has `ref` in it all the time.
>> You can't write code without those things.
>
> You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper.
>
> You can use pointers instead of ref, inconvenient, not a showstopper.

Do you really believe this, or are you just making up an excuse?

Putting @safe on declarations is inconvenient, but NOT a showstopper.

How much multi-threading work do you do on a daily basis? I think it would be best to leave what is and isn't a "showstopper" to the experts that do the work on a daily basis.

On Sunday, 7 June 2020 at 16:09:08 UTC, Greatsam4sure wrote:
> On Sunday, 7 June 2020 at 14:18:50 UTC, Steven Schveighoffer wrote:
>> [...]
>
>
> This thread has a specific purpose. The purpose is those people using D in production or their project, why are they using it. So that others can find confidence and use it too. It is not a thread to argue about D problems. Let keep the focus of the thread. This one of the most beautiful thread I have enjoyed since my two years plus of being this forum. Move all other discussions to another thread pls.....
>
Thank you! 🙏


> This thread if properly utilize or manage will be a great encouragement to a newbie in D tomorrow. I am really encouraged by D.
I really want to do something about promoting more of this.

>
> So we are waiting for more testimonies from happy users
Yes. Please share more testimonies.