What are (were) the most difficult parts of D?

[Steven Schveighoffer]

On 5/13/22 2:29 PM, Adam D Ruppe wrote:
> On Friday, 13 May 2022 at 18:23:58 UTC, H. S. Teoh wrote:
>> On Thu, May 12, 2022 at 11:45:47PM +0000, Guillaume Piolat via
>>> It's a problem because it goes from solving "no accidental race 
>>> condition" and you get "people forget to add shared or __gshared and 
>>> their shared library silently fail" situation. You could have none of 
>>> that with explicit TLS.
>>
>> Valid point.
> 
> Yeah, I used to be pro-TLS by default, then got bit by it several times 
> and moved to the fence, and now I'm anti.
> 
> Data races aren't actually prevented by it (maybe forcing you to specify 
> shared or tls would at least get you think about it though) and lots of 
> things mysteriously fail if you forget about it.

I disagree. I'd rather have a program fail in a way that is predictable 
and explainable than one with memory corruption or race conditions. In 
fact, I'd rather have 100 TLS confusion failures than one memory 
corruption failure.

Either way you will have failures due to under-specification. Which 
failures do you choose to debug?

Note that with the no shared access update, this will be more obvious of 
a mistake.

> This a case where I think forcing explitness would be better than either 
> default

Perhaps this would be reasonable. But I find the default reasonable too.

But we also have this confusing dynamic:

|scope   |no attribute| shared |static     |
|--------|------------|--------|-----------|
|module  |TLS         |global  |TLS (no-op)|
|function|local       |local!  |TLS        |
|class   |instance    |global  |TLS        |

Honestly, if we changed `static` storage class to `@tls`, and then 
required it whenever you wanted TLS data, it would be a huge improvement.

-Steve