Why do you continue to use D?

[Steven Schveighoffer]

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