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.

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.

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.

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.

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.

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.

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

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

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

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.