www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1028 "Make safe the Default" is dead

reply Walter Bright <newshound2 digitalmars.com> writes:
The subject says it all.

If you care about memory safety, I recommending adding `safe:` as the first
line 
in all your project modules, and annotate individual functions otherwise as 
necessary. For modules with C declarations, do as you think best.

For everyone else, carry on as before.
May 28
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Thanks Walter. I hope that Steve's recent auto-inference ideas might yet help us achieve your, widely shared, goal of expanding safe coverage/utility.
May 28
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 05:08:44 UTC, Bruce Carneal wrote:
 On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with 
 C declarations, do as you think best.

 For everyone else, carry on as before.
Thanks Walter. I hope that Steve's recent auto-inference ideas might yet help us achieve your, widely shared, goal of expanding safe coverage/utility.
Steve calls it "inferred-by-default", not "auto-inference". It looks like a great way to bring a ton-load of code in to the safe tent with low effort, but that's just the beginning.
May 28
prev sibling parent James Lu <jamtlu gmail.com> writes:
On Friday, 29 May 2020 at 05:08:44 UTC, Bruce Carneal wrote:
 Thanks Walter.
Thanks to everyone in the commmunity for being nice and saying "Thank you." As a cautionary tale, Guido Van Rossum, former BDFL of Python, resigned over flamewars on the := operator in Python, the same arguments were rehashed over and over.
May 30
prev sibling next sibling parent Mathias LANG <geod24 gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Thank you for listening to the community's feedback.
May 28
prev sibling next sibling parent Johannes Loher <johannes.loher fg4f.de> writes:
Am 29.05.20 um 06:53 schrieb Walter Bright:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` as the
 first line in all your project modules, and annotate individual
 functions otherwise as necessary. For modules with C declarations, do as
 you think best.
 
 For everyone else, carry on as before.
Thank you, Walter. I understand that this comes with a lot of frustration (and maybe bitterness and resignation). But I really appreciate your decision to respect the community's opinion. It is the right thing to do. You have my biggest respect.
May 28
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Great. Thanks for accepting the community's feedback. On the extern(C) issue, I wasn't convinced by your concerns about programmers taking the path of least syntactical resistance, BUT if that would really have been a serious problem, I think just keeping system as default really is the best solution: Ideally safe would be brainlessly easy to use, however currently it can't truly do its job without some level of understanding and effort on the part of the user. So, better to just leave the whole system off by default, than try to force it on people who can't or won't make the effort to use it correctly. (I say this even though I try to use safe as much as possible in my own code.)
May 28
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 29.05.20 06:53, Walter Bright wrote:
 The subject says it all. 
Thanks! For the record, this would have been my preference: fix safe, safe by default > fix safe, system by default > don't fix safe, system by default > don't fix safe, safe by default While this retraction improves matters in the short term, I think there is still potential for improvement. In particular, ` safe` is still broken for function prototypes.
 I recommending adding `safe:` as the first line in all your project modules
It would be great if ` safe:` did not affect declarations that would otherwise infer annotations.
May 29
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that would otherwise 
 infer annotations.
The idea is the simple, general rule that: attribute declaration; attribute { declaration; } attribute: declaration; behave the same way. C++ is full of special cases which nobody remembers until they bite. Having a simple, general rule with maybe a less favorable effect here and there is preferable to a complex set of special cases that try to do the optimal thing in each case.
May 29
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 The idea is the simple, general rule that:
There's already exceptions to that. public public void foo() {} is an error, whereas public: public void foo() {} is not.
 Having a simple, general rule with maybe a less favorable 
 effect here and there is preferable to a complex set of special 
 cases that try to do the optimal thing in each case.
Often many things can be a simple, general rule based on how you word it. Let's say "attribute: changes the default attribute set of non-inferred subsequent declarations. attribute{} changes the default attribute set of non-inferred child declarations." That is simple and covers the cases sensibly. Big step up from where we are today.
May 29
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 2:38 PM, Adam D. Ruppe wrote:
 On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 The idea is the simple, general rule that:
There's already exceptions to that. public public void foo() {} is an error, whereas public:   public void foo() {} is not.
Is it really an exception? public public: // error public public { } // error
 Let's say "attribute: changes the default attribute set of non-inferred 
 subsequent declarations. attribute{} changes the default attribute set of 
 non-inferred child declarations."
The inferred set changes over time, this would become problematic.
May 30
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 21:38:40 UTC, Adam D. Ruppe wrote:
 On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 The idea is the simple, general rule that:
There's already exceptions to that. public public void foo() {} is an error, whereas public: public void foo() {} is not.
 Having a simple, general rule with maybe a less favorable 
 effect here and there is preferable to a complex set of 
 special cases that try to do the optimal thing in each case.
Often many things can be a simple, general rule based on how you word it. Let's say "attribute: changes the default attribute set of non-inferred subsequent declarations. attribute{} changes the default attribute set of non-inferred child declarations." That is simple and covers the cases sensibly. Big step up from where we are today.
This seems like a good idea. Simple and enabling.
May 30
prev sibling next sibling parent Arine <arine1283798123 gmail.com> writes:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that 
 would otherwise infer annotations.
The idea is the simple, general rule that: attribute declaration; attribute { declaration; } attribute: declaration; behave the same way. C++ is full of special cases which nobody remembers until they bite. Having a simple, general rule with maybe a less favorable effect here and there is preferable to a complex set of special cases that try to do the optimal thing in each case.
D already has a bunch of special cases such as this. It happens a lot with attributes because of the "attribute:" syntax and behavior. Otherwise "attribute:" would be useless if it error'd on everything that isn't valid. const int x = 37; safe int* p = cast(int*) &x; // ok safe: int* p = cast(int*) &x; // error In the case of declarations, there usually aren't that many littered about. So instead of having it be silent giving an error message would be better. Sure it's still a "special" rule, but it's not one that will silently jump out at you like in the above case.
May 29
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that 
 would otherwise infer annotations.
The idea is the simple, general rule that: attribute declaration; attribute { declaration; } attribute: declaration; behave the same way.
To preserve this, then please can we have ` safe module foo;`. This would change the default on a module basis to safe, but still infer e.g. function template bodies as system where necessary. This feature would allow modules from different projects, including ones written before this feature would be added can coexist happily. There would be no breakage, unlike DIP 1028 (which I BTW would support at a lower preference than the above feature, apart from unmarked extern(C) declarations being safe).
May 30
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/30/20 7:39 AM, Nick Treleaven wrote:
 On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that would 
 otherwise infer annotations.
The idea is the simple, general rule that:   attribute declaration;   attribute { declaration; }   attribute: declaration; behave the same way.
To preserve this, then please can we have ` safe module foo;`. This would change the default on a module basis to safe, but still infer e.g. function template bodies as system where necessary. This feature would allow modules from different projects, including ones written before this feature would be added can coexist happily. There would be no breakage, unlike DIP 1028 (which I BTW would support at a lower preference than the above feature, apart from unmarked extern(C) declarations being safe).
+1 this would be perfect. Not sure if this would work either, but both of these are already reserved words: default safe: -Steve
May 30
parent Paul Backus <snarwin gmail.com> writes:
On Saturday, 30 May 2020 at 16:17:49 UTC, Steven Schveighoffer 
wrote:
 +1 this would be perfect.

 Not sure if this would work either, but both of these are 
 already reserved words:

 default  safe:

 -Steve
It would probably have to be something more like `default( safe)`, since `default safe:` ought to mean the same thing (in principle) as `default: safe:`.
May 30
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/20 7:39 AM, Nick Treleaven wrote:
 On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that would 
 otherwise infer annotations.
The idea is the simple, general rule that:   attribute declaration;   attribute { declaration; }   attribute: declaration; behave the same way.
To preserve this, then please can we have ` safe module foo;`.
We already have that in Yoda notation: module foo; safe:
May 30
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
 On 5/30/20 7:39 AM, Nick Treleaven wrote:
 On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
 On 5/29/2020 2:07 AM, Timon Gehr wrote:
 It would be great if ` safe:` did not affect declarations that would 
 otherwise infer annotations.
The idea is the simple, general rule that:   attribute declaration;   attribute { declaration; }   attribute: declaration; behave the same way.
To preserve this, then please can we have ` safe module foo;`.
We already have that in Yoda notation: module foo; safe:
Again, not the same. Read the full thread that you quoted above. -Steve
May 30
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 30 May 2020 at 20:14:04 UTC, Steven Schveighoffer 
wrote:
 On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
 module foo;  safe:
Again, not the same. Read the full thread that you quoted above.
And even aside from inference, it doesn't actually work for most the attributes. safe is the exception, it DOES descend into classes and structs. But the others don't. We should make this actually work for everything. 1) Make inferred_attr: NOT apply to template/auto functions. 2) Add inverse attributes for all things. (or tri-state, true/false/null) 3) Solve the child scope problem somehow consistently.
May 30
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 30 May 2020 at 20:29:37 UTC, Adam D. Ruppe wrote:
 On Saturday, 30 May 2020 at 20:14:04 UTC, Steven Schveighoffer 
 wrote:
 On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
 module foo;  safe:
Again, not the same. Read the full thread that you quoted above.
And even aside from inference, it doesn't actually work for most the attributes. safe is the exception, it DOES descend into classes and structs. But the others don't. We should make this actually work for everything. 1) Make inferred_attr: NOT apply to template/auto functions. 2) Add inverse attributes for all things. (or tri-state, true/false/null) 3) Solve the child scope problem somehow consistently.
+1 This could take us a good way out of the "attribute swamp".
May 30
prev sibling parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Saturday, 30 May 2020 at 20:29:37 UTC, Adam D. Ruppe wrote:
 We should make this actually work for everything.

 1) Make inferred_attr: NOT apply to template/auto functions.
 2) Add inverse attributes for all things. (or tri-state, 
 true/false/null)
 3) Solve the child scope problem somehow consistently.
+1. Would be great to see the possibility to apply other built-in attributes on a module basis, like ` nogc module test;` or ` trusted module test` etc. It seems very natural to expect this feature to work in that way. The only problem is what to do with UDAs, but probably they also should be applied to everything in the same manner.
Jun 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/30/2020 4:39 AM, Nick Treleaven wrote:
 To preserve this, then please can we have ` safe module foo;`. This would
change 
 the default on a module basis to  safe, but still infer e.g. function template 
 bodies as  system where necessary. This feature would allow modules from 
 different projects, including ones written before this feature would be added 
 can coexist happily. There would be no breakage, unlike DIP 1028 (which I BTW 
 would support at a lower preference than the above feature, apart from
unmarked 
 extern(C) declarations being  safe).
The implementation PR for DIP1028 still allowed inference for templates as before.
May 31
parent Avrina <avrina12309412342 gmail.com> writes:
On Sunday, 31 May 2020 at 19:15:19 UTC, Walter Bright wrote:
 On 5/30/2020 4:39 AM, Nick Treleaven wrote:
 To preserve this, then please can we have ` safe module foo;`. 
 This would change the default on a module basis to  safe, but 
 still infer e.g. function template bodies as  system where 
 necessary. This feature would allow modules from different 
 projects, including ones written before this feature would be 
 added can coexist happily. There would be no breakage, unlike 
 DIP 1028 (which I BTW would support at a lower preference than 
 the above feature, apart from unmarked extern(C) declarations 
 being  safe).
The implementation PR for DIP1028 still allowed inference for templates as before.
In a safe-by-default world, ` system:` doesn't. In a system-by-default world, ` safe:` doesn't. This has been discussed verbatim in the DIP1028 threads.
May 31
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Thank you Walter.
May 29
prev sibling next sibling parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Can we get a compiler flag that will enable safe by default for people who might want it?
May 29
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 2:53 AM, solidstate1991 wrote:
 Can we get a compiler flag that will enable safe by default for people who
might 
 want it?
It would balkanize the language.
May 30
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/28/20 9:53 PM, Walter Bright wrote:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` as the 
 first line in all your project modules, and annotate individual 
 functions otherwise as necessary. For modules with C declarations, do as 
 you think best.
 
 For everyone else, carry on as before.
Thank you! Which meme did it? :o) Ali
May 29
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 3:36 AM, Ali Çehreli wrote:
 Thank you! Which meme did it? :o)
My secret!
May 29
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Thank you Walter. I am sure this was not an easy decision, and I respect how you have handled the response. I think one important takeaway from this should be that people were not opposed to "memory safety by default." Instead, they were opposed to " safe in its current implementation by default." In terms of changing the behavior of safe, I think it would be useful to review comments on this old bug report [1] about changing safe to a whitelist instead of blacklist. I think if safe was a whitelist instead of a blacklist, the concerns about safe's current implementation would be diminished. I also think some of the comments on the thread discussing the DIP procedure are also relevant for improving the DIP process going forward. In particular, creating a small DIP committee, perhaps consisting of the Language Maintainers, the principal maintainers of LDC and GDC, and maybe one person elected by the community (hopefully Andrei if he has time to volunteer), that would discuss each DIP before voting might help make a more robust decision. If the current process is continued, then we could add a rule that the DIP author may not participate in final DIP votes and he should be replaced by an alternate. I'm not sure how important that would be with a committee-based approach, but worth considering. [1] https://issues.dlang.org/show_bug.cgi?id=12941
May 29
next sibling parent Douglas <overprose gmail.com> writes:
On Friday, 29 May 2020 at 11:04:00 UTC, jmh530 wrote:
 On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 [...]
Thank you Walter. I am sure this was not an easy decision, and I respect how you have handled the response. [...]
I would think that Phobis maintainers would make good candidates here.
May 29
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Friday, 29 May 2020 at 11:04:00 UTC, jmh530 wrote:
 On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 [...]
Thank you Walter. I am sure this was not an easy decision, and I respect how you have handled the response. I think one important takeaway from this should be that people were not opposed to "memory safety by default." Instead, they were opposed to " safe in its current implementation by default." In terms of changing the behavior of safe, I think it would be useful to review comments on this old bug report [1] about changing safe to a whitelist instead of blacklist. I think if safe was a whitelist instead of a blacklist, the concerns about safe's current implementation would be diminished. I also think some of the comments on the thread discussing the DIP procedure are also relevant for improving the DIP process going forward. In particular, creating a small DIP committee, perhaps consisting of the Language Maintainers, the principal maintainers of LDC and GDC, and maybe one person elected by the community (hopefully Andrei if he has time to volunteer), that would discuss each DIP before voting might help make a more robust decision.
I wouldn't disagree with being made inclusive on the final decision making (though in this case I don't think it would have changed the outcome). However, I would regard myself as a language implementer, not a language designer (nor library maintainer).
May 30
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/29/20 12:53 AM, Walter Bright wrote:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` as the 
 first line in all your project modules, and annotate individual 
 functions otherwise as necessary. For modules with C declarations, do as 
 you think best.
 
 For everyone else, carry on as before.
Thank you Walter. I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece. It would be nice to be able to put safe: at the top of all modules. This was in fact the first thing I tried when migrating the mysql-native package to be safe compliant [1]. And it did work for a few modules quite well. There are a few snags though: 1. Templates should be inferred rather than stamped safe 2. Class methods do not inherit this attribute So I think safe by default (for D-compiled code) would be ideal and provide the most utility. -Steve [1] https://github.com/mysql-d/mysql-native/pull/214
May 29
parent reply Meta <jared771 gmail.com> writes:
On Friday, 29 May 2020 at 12:22:07 UTC, Steven Schveighoffer 
wrote:
 On 5/29/20 12:53 AM, Walter Bright wrote:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with 
 C declarations, do as you think best.
 
 For everyone else, carry on as before.
Thank you Walter. I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece.
It's not unfortunate - it's unnecessary. safe by default is still a laudable and (seemingly) attainable goal. Why throw out the entire DIP instead of removing or altering the controversial aspect?
May 29
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, May 29, 2020 6:48:20 AM MDT Meta via Digitalmars-d-announce wrote:
 On Friday, 29 May 2020 at 12:22:07 UTC, Steven Schveighoffer

 wrote:
 On 5/29/20 12:53 AM, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:`
 as the first line in all your project modules, and annotate
 individual functions otherwise as necessary. For modules with
 C declarations, do as you think best.

 For everyone else, carry on as before.
Thank you Walter. I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece.
It's not unfortunate - it's unnecessary. safe by default is still a laudable and (seemingly) attainable goal. Why throw out the entire DIP instead of removing or altering the controversial aspect?
IIRC, based on how the DIP process it works, if a DIP gets rejected, it basically has to go through the whole process again. Walter could certainly make an executive decision to skip that process and just implement an altered version of the DIP, but as much flak as he's gotten over his DIPs, he's very much been trying to stick to the process rather than simply implementing his ideas. Now, whether in the future, we'll get a DIP proposing safe as the default for all code that the compiler can check while leaving it system for the code that it can't, I don't know. The way that Walter stated that DIP 1028 was dead kind of implies that he's given up on it entirely, but we'll have to wait and see. Based on what he's said, it seems like he may be convinced that safe by default will result in trusted being used inappropriately way too much if extern(C) declarations aren't safe by default (in which case, making safe the default would actually make things worse), and he clearly thought that treating declarations differently from definitions would mean adding an exception to the rules and that such an exception would be very negative. - Jonathan M Davis
May 29
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/29/20 12:53 AM, Walter Bright wrote:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` as the 
 first line in all your project modules, and annotate individual 
 functions otherwise as necessary. For modules with C declarations, do as 
 you think best.
 
 For everyone else, carry on as before.
Thank you. Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.
May 29
next sibling parent reply SashaGreat <s g.com> writes:
On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
 ...
 Unrelated to this decision, I wanted to apologize for having 
 lowered the quality of discourse in this forum.
I think you should. To be honest first I thought it was a fake account, because your behavior wasn't great (Technically speaking). SG.
May 29
parent Faux Amis <faux amis.com> writes:
On 2020-05-29 16:13, SashaGreat wrote:
 On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
 ...
 Unrelated to this decision, I wanted to apologize for having lowered 
 the quality of discourse in this forum.
I think you should. To be honest first I thought it was a fake account, because your behavior wasn't great (Technically speaking). SG.
Same here
May 29
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 13:11:29 UTC, Andrei Alexandrescu wrote:
 On 5/29/20 12:53 AM, Walter Bright wrote:
 The subject says it all.
 
 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with 
 C declarations, do as you think best.
 
 For everyone else, carry on as before.
Thank you. Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.
By my lights you've already set a high standard. Certainly I have further to go in that regard than you do. Timon and others also continue to impress. Thanks again to Walter for crossing any divide which the loyal opposition may have thrown up.
May 29
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
This is sad news. I was excited for safe-by-default, and had hoped that the issue with extern(C) could be solved without throwing DIP 1028 away entirely. I hope that you and Atila do not take the reception of DIP 1028 as a blow against safe in general, and that you will continue to look for ways to improve the safety of the D language.
May 29
next sibling parent Faux Amis <faux amis.com> writes:
On 2020-05-29 16:22, Paul Backus wrote:
 On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` as the 
 first line in all your project modules, and annotate individual 
 functions otherwise as necessary. For modules with C declarations, do 
 as you think best.

 For everyone else, carry on as before.
This is sad news. I was excited for safe-by-default, and had hoped that the issue with extern(C) could be solved without throwing DIP 1028 away entirely. I hope that you and Atila do not take the reception of DIP 1028 as a blow against safe in general, and that you will continue to look for ways to improve the safety of the D language.
Agreed, from a novice perspective safe by default looks like the way to go.
May 29
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 7:22 AM, Paul Backus wrote:
 This is sad news. I was excited for  safe-by-default, and had hoped that the 
 issue with extern(C) could be solved without throwing DIP 1028 away entirely.
I watched a documentary on Clive Davis (famous recording executive) the other day. He would advise his clients, like Kenny G, Barry Manilow, etc., on how they should arrange and position their songs. Kenny G (famous clarinet player) said Davis recommended he add a vocal track, as that will sell more records. KG asks are you advising, or telling me? Davis says he's advising. KG does it his own way, and the record is a hit. KG triumphantly tells Davis what do you think of that now? Davis replies if KG had followed his advice, he'd have sold even more records.
May 29
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 29 May 2020 at 20:36:12 UTC, Walter Bright wrote:
 On 5/29/2020 7:22 AM, Paul Backus wrote:
 This is sad news. I was excited for  safe-by-default, and had 
 hoped that the issue with extern(C) could be solved without 
 throwing DIP 1028 away entirely.
I watched a documentary on Clive Davis (famous recording executive) the other day. He would advise his clients, like Kenny G, Barry Manilow, etc., on how they should arrange and position their songs. Kenny G (famous clarinet player) said Davis recommended he add a vocal track, as that will sell more records. KG asks are you advising, or telling me? Davis says he's advising. KG does it his own way, and the record is a hit. KG triumphantly tells Davis what do you think of that now? Davis replies if KG had followed his advice, he'd have sold even more records.
I’m not sure who in this analogy is the Kenny G and who the Clive Davis, and we probably will never know for sure. Off topic, and without extending the analogy, I had never heard about Kenny G until I came across Pat Metheny’s rant about him. It’s a well reasoned critique, and it seems to me that the expertise in our community is a lot higher than Kenny G’s musical expertise. http://www.jazzoasis.com/methenyonkennyg.htm — Bastiaan
May 29
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2020 4:47 PM, Bastiaan Veelo wrote:
 I’m not sure who in this analogy is the Kenny G and who the Clive Davis,
Haha, I was deliberately vague about that, so people could interpret it as they pleased.
 Off topic, and without extending the analogy, I had never heard about Kenny G
He was the big cheese about 30 years ago.
 until I came across Pat Metheny’s rant about him. It’s a well reasoned
critique, 
 and it seems to me that the expertise in our community is a lot higher than 
 Kenny G’s musical expertise.
 http://www.jazzoasis.com/methenyonkennyg.htm
From your cite: "This controversy seems to be largely fueled by the fact that he sells an enormous amount of records while not being anywhere near a really great player in relation to the standards that have been set on his instrument over the past sixty or seventy years." This is where Clive Davis comes in, who apparently had a "golden ear" for what would be commercially successful and what wouldn't. He made a long stream of nobodies into celebrities. Whitney Houston was another. The documentary is a great counterpart to the popular notion that record companies only take advantage of the artists.
May 29
prev sibling parent bpr <brogoff gmail.com> writes:
On Friday, 29 May 2020 at 20:36:12 UTC, Walter Bright wrote:
 Kenny G (famous clarinet player)
Soprano saxophone, not clarinet. They look similar, and are both Bb instruments (I know there are non Bb clarinets), but they don't sound that similar to me. Kenny G is also sometimes heard on other saxes, but I've never heard him on clarinet.
May 29
prev sibling next sibling parent Johannes T <isrvoid gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.
Thanks a lot for your effort! Judging by the responses, there should be another attempt after addressing some issues. I have an idea that could mitigate greenwashing of extern (I know everyone hates that term by now, sorry) while keeping it system. I'll summarize it separately to gauge if a DIP should be event considered.
May 29
prev sibling next sibling parent neikeq <ignalfonsore gmail.com> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.

 For everyone else, carry on as before.
Does this mean there's no longer an interest in making safe the default? Or is it only DIP 1028 that's being dropped in favor of a future new DIP? safe seemed to be the way to go. It would be a pitty to discard the entire thing because of the extern(C) issue, which seemed addressable within DIP 1028 IMO.
May 29
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 28, 2020 10:53:07 PM MDT Walter Bright via Digitalmars-d-
announce wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` as the first
 line in all your project modules, and annotate individual functions
 otherwise as necessary. For modules with C declarations, do as you think
 best.

 For everyone else, carry on as before.
Thank you. - Jonathan M Davis
May 29
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
 The subject says it all.

 If you care about memory safety, I recommending adding `safe:` 
 as the first line in all your project modules, and annotate 
 individual functions otherwise as necessary. For modules with C 
 declarations, do as you think best.
I don't think this is the best way forward. Though I've only skim read the discussion thread (mostly only reading posts by those I know in person), I am inferring that both extremes - extern safe and extern system - both suffer from the same defect in DIP 1018 with regards to the greenwashing problem. It also looks like all current suggestions for a compromise on the matter are pretty woeful as well (though I don't pretend to have read them all). It seems that there will have to be some restrictions in place that prevent inappropriate annotations, at the cost of long deprecations and breaking existing code. I don't see any point in listing any such rules though unless the dip process is restarted.
May 30