On 4/12/2023 12:38 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 12/04/2023 7:27 PM, Walter Bright wrote:
>> On 4/12/2023 12:11 AM, Richard (Rikki) Andrew Cattermole wrote:
>>> Unless proven otherwise, all memory is owned by the process not the thread and therefore is the default.
>>
>> Let's see if I understand:
>>
>>      int abc(int* p);
>>
>>      int sum(int[] a)
>>      {
>>          int sum = 0;
>>          abc(&sum);
>>          for (int i = 0; i < a.length; ++i)
>>              sum += a[i];
>>          return sum;
>>      }
>>
>> Your position is that `i` and `sum` should be shared variables? What if `abc(&sum)` passes `&sum` to a concurrent thread?
> 
> No, you have that backwards.
> 
> In both of those cases its owned by the thread. With @safe they would be scope, which is a partial implementation of 'owned by thread' checking.

Then I don't know what you mean by default being shared. And why would @safe influence this?


> A better example would be `a`. This is an argument, with an unknown memory lifetime or ownership, that should be shared implicitly even if it was marked scope.

Such implicit sharing means C semantics, where the compiler assumes that none of it is shared, and there are no protections and it's all up to the programmer to put in synchronization code where necessary.

You can actually do that now in D, just leave off the 'shared' annotations.

On 13/04/2023 5:06 AM, Walter Bright wrote:
>> In both of those cases its owned by the thread. With @safe they would be scope, which is a partial implementation of 'owned by thread' checking.
> 
> Then I don't know what you mean by default being shared. And why would @safe influence this?

Default being shared I mean in terms of equivalence of behavior and purpose of shared itself.

@safe influences it because of DIP1000 with scope, which gives memory a lifetime that is tracked across a thread.

>> A better example would be `a`. This is an argument, with an unknown memory lifetime or ownership, that should be shared implicitly even if it was marked scope.
> 
> Such implicit sharing means C semantics, where the compiler assumes that none of it is shared, and there are no protections and it's all up to the programmer to put in synchronization code where necessary.
> 
> You can actually do that now in D, just leave off the 'shared' annotations.

Exactly. You can leave it off and you have the same guarantees you have with shared being on (ignoring nosharedaccess as that is essentially turning it into atomic without any of the QoL stuff).

We can talk about this some other time perhaps at a BeerConf if you're on when I can talk. I do have a lot of things to talk about that are a bit exciting (and plenty of bugs like unresolved RTInfoImpl's with dmd)!

On 4/12/2023 10:50 PM, Richard (Rikki) Andrew Cattermole wrote:
> We can talk about this some other time perhaps at a BeerConf if you're on when I can talk. I do have a lot of things to talk about that are a bit exciting (and plenty of bugs like unresolved RTInfoImpl's with dmd)!

Ok. But I suggest writing down your thoughts, complete with examples and such. I have a hard time picturing just what your proposal is.

On 14/04/2023 7:38 AM, Walter Bright wrote:
> On 4/12/2023 10:50 PM, Richard (Rikki) Andrew Cattermole wrote:
>> We can talk about this some other time perhaps at a BeerConf if you're on when I can talk. I do have a lot of things to talk about that are a bit exciting (and plenty of bugs like unresolved RTInfoImpl's with dmd)!
> 
> Ok. But I suggest writing down your thoughts, complete with examples and such. I have a hard time picturing just what your proposal is.

- Remove ``shared(T)``
- Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode (like -preview=nosharedaccess introduces, or having to cast away shared).

Basically everything I have to say is rather academic in nature, not very practical, there are arguments both for and against everything practical I can suggest.

From my reading of research papers regarding coroutines, pretty much all the concurrency primitives that we know of today for PL design was already invented by 1976 with an implementation; this is very much an open problem still.

I really enjoyed this particular passage from one paper as it shows just how little things have changed in 50 years:

> However, this paper also ignores many serious problems. The most serious is that it fails to suggest any proof method to assist in the development and verification of correct programs.

On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:
>
> Thoughts? I'm going to do D1.5 for myself but wanted to know if anyone feels the same.

Whether forwards or backwards, someone should first write a paper/article/whatever, exploring 'the darker side of D'.

We need a 'Markku Sakkinen' like paper (he wrote one back in the early 90s called "The darker side of C++ revisited".

I expect some people over at Micrsoft had a good read of that paper before setting off to create C#.

My guess is, his view has still not changed:

"..taking the weakly typed and weakly structured language C as a base has become an irremediable handicap."