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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Thank you Walter.
May 29 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020