On Thursday, 2 January 2020 at 06:40:23 UTC, Walter Bright wrote:
> On 1/1/2020 9:53 PM, Manu wrote:
>> On Thu, Jan 2, 2020 at 3:40 PM Mike Parker via Digitalmars-d-announce
>> <digitalmars-d-announce@puremagic.com> wrote:
>>>
>>> DIP 1024, "Shared Atomics", was accepted without comment.
>>>
>>> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md
>> 
>> This has been a long time coming!
>
> A New Year's present for all of us!

Thank you Walter!

On 1/3/2020 3:41 AM, Manu wrote:
> We've already had this -preview for quite a while; I have enabled it
> in an experimental context, but I don't tend to write and deploy code
> that depends on future-features. I stick to the current language when
> writing code I intend to share.
> Do you have some sense of when we will make this part of the language?
> The DIP is accepted, but it didn't describe that it would be enabled
> at some future time...?

You shouldn't be reluctant to use preview switches. It's only that way to ease the transition for people, not because we're going to withdraw it.

Don't really have a schedule at the moment. It'll likely be at least a year.

On Sat, Jan 4, 2020 at 2:15 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/3/2020 3:41 AM, Manu wrote:
> > We've already had this -preview for quite a while; I have enabled it
> > in an experimental context, but I don't tend to write and deploy code
> > that depends on future-features. I stick to the current language when
> > writing code I intend to share.
> > Do you have some sense of when we will make this part of the language?
> > The DIP is accepted, but it didn't describe that it would be enabled
> > at some future time...?
>
> You shouldn't be reluctant to use preview switches. It's only that way to ease the transition for people, not because we're going to withdraw it.

Well it was a preview for an unaccepted DIP, so it could have been withdrawn. I guess I have increased confidence now, but it still seems unnecessary to delay.

> Don't really have a schedule at the moment. It'll likely be at least a year.

A year? That's disappointing. What is the reason to delay this? It doesn't break anything, and it likely fixes bugs on contact.

On Thursday, 2 January 2020 at 09:41:02 UTC, Walter Bright wrote:
> On 1/2/2020 12:01 AM, Manu wrote:
>> Quick quick, we need a PR to issue deprecation messages for those
>> invalid read/writes! :)
>
> It's already been merged!
>
> https://github.com/dlang/dmd/pull/10209
>
> Some really fast work there :-)

Nice.

There was some initial work on shared a long while back: https://github.com/dlang/dmd/commit/276a69327652be8d95607cec142790baae110d0c

It's interesting it took this long to push it to the end. :)

On 1/6/2020 10:17 PM, Manu wrote:
> Well it was a preview for an unaccepted DIP, so it could have been
> withdrawn. I guess I have increased confidence now, but it still seems
> unnecessary to delay.

Preview means for accepted DIPs as well when they break existing code.

>> Don't really have a schedule at the moment. It'll likely be at least a year.
> A year? That's disappointing. What is the reason to delay this? It
> doesn't break anything, and it likely fixes bugs on contact.

It breaks all code that manipulates shared data directly, whether it was correctly written or not.

On Wed, Jan 8, 2020 at 12:20 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/6/2020 10:17 PM, Manu wrote:
> > Well it was a preview for an unaccepted DIP, so it could have been withdrawn. I guess I have increased confidence now, but it still seems unnecessary to delay.
>
> Preview means for accepted DIPs as well when they break existing code.
>
> >> Don't really have a schedule at the moment. It'll likely be at least a year.
> > A year? That's disappointing. What is the reason to delay this? It doesn't break anything, and it likely fixes bugs on contact.
>
> It breaks all code that manipulates shared data directly, whether it was correctly written or not.

It will still do that, either now... or later. So, why wait?

On Wednesday, 8 January 2020 at 02:31:24 UTC, Manu wrote:
> On Wed, Jan 8, 2020 at 12:20 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> It will still do that, either now... or later. So, why wait?

Since @safe and shared is all syntactical in nature then all these problems can be avoided by just adding compiler switches:

-ignore-shared, -ignore-safe etc...

On 1/7/2020 6:31 PM, Manu wrote:
> It will still do that, either now... or later. So, why wait?

Because customers have their own schedules.

On Thu, Jan 9, 2020 at 6:35 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/7/2020 6:31 PM, Manu wrote:
> > It will still do that, either now... or later. So, why wait?
>
> Because customers have their own schedules.

Customers update their compilers according to their schedules, and
they can use `-revert` if they're not ready to migrate, that's the
whole point...
You didn't answer me though, if it's accepted, and it's implemented...
why not enable it? and when will we do it?
Explain the reason for the delay or choice in timing? The transition
you describe must happen at some time... and delay changes nothing;
the transition is exactly the same.

On 02/01/2020 09:01, Manu wrote:
> On Thu, Jan 2, 2020 at 4:45 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> On 1/1/2020 9:53 PM, Manu wrote:
>>> On Thu, Jan 2, 2020 at 3:40 PM Mike Parker via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>>>
>>>> DIP 1024, "Shared Atomics", was accepted without comment.
>>>>
>>>> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md
>>>
>>> This has been a long time coming!
>>
>> A New Year's present for all of us!
> 
> Quick quick, we need a PR to issue deprecation messages for those invalid read/writes! :)
> 

Before making the new semantics the default, the next step should be to make druntime and phobos compile with the preview-switch. That didn't seem like a no-brainer to me when I recently tried that (but only for a couple of minutes), especially with shared being applied to class/struct declarations.