www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1024---Shared Atomics---Accepted

reply Mike Parker <aldacron gmail.com> writes:
DIP 1024, "Shared Atomics", was accepted without comment.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md
Jan 01
parent reply Manu <turkeyman gmail.com> writes:
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!
Jan 01
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Jan 01
next sibling parent reply Manu <turkeyman gmail.com> writes:
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! :)
Jan 02
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Jan 02
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Thu, Jan 2, 2020 at 7:45 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 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 :-)
Doesn't the acceptance of the DIP suggest that it should no longer be `-preview`; it should be enabled and an option to disable the feature via `-revert` should be introduced? Or short of that, a deprecation message should be emit when compiling?
Jan 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2020 4:17 AM, Manu wrote:
 On Thu, Jan 2, 2020 at 7:45 PM Walter Bright via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 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 :-)
Doesn't the acceptance of the DIP suggest that it should no longer be `-preview`; it should be enabled and an option to disable the feature via `-revert` should be introduced?
We switch to -revert after some time has passed (a year or two) so people have time to adapt.
 Or short of that, a deprecation message should be emit when compiling?
I'm not sure that's necessary with the preview/revert switches.
Jan 02
parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jan 3, 2020 at 9:20 AM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On 1/2/2020 4:17 AM, Manu wrote:
 On Thu, Jan 2, 2020 at 7:45 PM Walter Bright via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 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 :-)
Doesn't the acceptance of the DIP suggest that it should no longer be `-preview`; it should be enabled and an option to disable the feature via `-revert` should be introduced?
We switch to -revert after some time has passed (a year or two) so people have time to adapt.
 Or short of that, a deprecation message should be emit when compiling?
I'm not sure that's necessary with the preview/revert switches.
Okay, although I don't really understand; if we have accepted the feature, but we don't enable the feature... then nobody will use it, and no code will be written that's compatible. This kinda seems like a future-acceptance? Nobody enables `-preview`s.
Jan 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2020 11:31 PM, Manu wrote:
 Okay, although I don't really understand; if we have accepted the
 feature, but we don't enable the feature... then nobody will use it,
 and no code will be written that's compatible.
 This kinda seems like a future-acceptance?
 Nobody enables `-preview`s.
Those who need it (you!) will use it. That's what matters.
Jan 03
parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jan 3, 2020 at 8:35 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On 1/2/2020 11:31 PM, Manu wrote:
 Okay, although I don't really understand; if we have accepted the
 feature, but we don't enable the feature... then nobody will use it,
 and no code will be written that's compatible.
 This kinda seems like a future-acceptance?
 Nobody enables `-preview`s.
Those who need it (you!) will use it. That's what matters.
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...?
Jan 03
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 03
parent reply Manu <turkeyman gmail.com> writes:
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.
Jan 06
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 07
parent reply Manu <turkeyman gmail.com> writes:
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?
Jan 07
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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...
Jan 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 09
parent reply Manu <turkeyman gmail.com> writes:
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.
Jan 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/10/2020 2:48 PM, Manu wrote:
 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.
We decided a couple years ago to implement disruptive new features first with -preview=feature, and some time later make it the default and have a -revert=feature. So far, it has worked well. I don't see any reason to change it.
Jan 13
parent Manu <turkeyman gmail.com> writes:
On Mon, Jan 13, 2020 at 1:40 AM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On 1/10/2020 2:48 PM, Manu wrote:
 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.
We decided a couple years ago to implement disruptive new features first with -preview=feature, and some time later make it the default and have a -revert=feature. So far, it has worked well. I don't see any reason to change it.
Yes, but we've had the -preview for close to a year now... I'm asking what "some time later" means? Obviously the lib needs to be fixed (that Rainer pointed out).
Jan 13
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. :)
Jan 06
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Jan 11
prev sibling parent bauss <jj_1337 live.dk> writes:
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!
Jan 03