Re: DIP 1028 "Make @safe the Default" is dead
On 5/29/2020 3:36 AM, Ali Çehreli wrote: Thank you! Which meme did it? :o) My secret!
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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*) // ok
@safe: int* p = cast(int*) // 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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: D IDE Dexed - v3.9.0
On Friday, 29 May 2020 at 08:04:12 UTC, Basile B. wrote: I've fixed it yesterday (https://gitlab.com/basile.b/dexed/-/commit/730c2a4e6e1ae18d603d91c471bf3b6459ce7b52) using my mom's laptop ^^. Fortunately I've found an old post from p0nce (https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org) that explained in detail how to make dll on win and the error has become obvious. IMPORTANT: Use `export` for any call you want exported in your DLL! Also in IDA the list of the exports showed nothing... that was a huge f**ing clue. anyway the Windows version is verified to work now. Only thing is that a msvc140.dll might be necessary, but this is not a dexed problem. In this case people can just get it from the official microsoft website. confirmed ;) Thank YOU... and your mom :D
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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
German D tutorial: Sichere Docker images für cloud Anwendungen erstellen
Hi, This tutorial describes how to run a vibe-d http server within a docker scratch image for the purpose of security. https://d-land.sepany.de/tutorials/cloud/sichere-docker-images-fuer-cloud-anwendungen-erstellen/ Kind regards Andre
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: unit-threaded v1.0.0
On 28.05.20 17:35, Atila Neves wrote:
https://code.dlang.org/packages/unit-threaded
You got a bad @trusted:
import unit_threaded.light: check;
void main() @safe
{
check!((int a) @system {
/* ... can do unsafe stuff here ... */
return true;
});
}
I searched for "trusted" and that was the first hit. I didn't look
further. There's probably more.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: DIP 1028 "Make @safe the Default" is dead
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?
Re: Rationale for accepting DIP 1028 as is
On Friday, 29 May 2020 at 11:33:01 UTC, Sebastiaan Koppe wrote: On Thursday, 28 May 2020 at 16:01:35 UTC, Johannes Pfau wrote: [snip] This would be another round of massively breaking user code. The breakage will be split in two rounds, but the amount of code needed to be modified would be the same as with the safe-by-default-except-for-extern-non-c. With the possibility of not needing the second round. I know, arguing for a lost cause... At the end of the day, I think people would accept "massively breaking user code" if there is a good justification and doesn't drive a hole through @safe.
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: Rationale for accepting DIP 1028 as is
On Thursday, 28 May 2020 at 16:01:35 UTC, Johannes Pfau wrote: Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe: If it does come back to haunt him, he can always add a DIP to make extern(!D) @system by default. It won't invalidate any work. This would be another round of massively breaking user code. The breakage will be split in two rounds, but the amount of code needed to be modified would be the same as with the safe-by-default-except-for-extern-non-c. With the possibility of not needing the second round. I know, arguing for a lost cause...
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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
Re: DIP 1028 "Make @safe the Default" is dead
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?
Re: DIP 1028 "Make @safe the Default" is dead
Thank you Walter.
Re: DIP 1028 "Make @safe the Default" is dead
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.
Re: D IDE Dexed - v3.9.0
On Saturday, 9 May 2020 at 11:33:08 UTC, notna wrote: On Friday, 8 May 2020 at 00:46:04 UTC, Basile B. wrote: Sorry, I'm tempted to drop official Windows support good. I have an old win7 DVD but I'd prefer if someone who actually uses Windows could fix this. For now let's talk here https://gitlab.com/basile.b/dexed/-/issues/37, as it is very specific. Thanks... seems like I was the only one interested in using it on Windows, so... most of the time I use VSCodium with the great code-d plugin by now anyhow, so I will survive also without dexed ;) I've fixed it yesterday (https://gitlab.com/basile.b/dexed/-/commit/730c2a4e6e1ae18d603d91c471bf3b6459ce7b52) using my mom's laptop ^^. Fortunately I've found an old post from p0nce (https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org) that explained in detail how to make dll on win and the error has become obvious. IMPORTANT: Use `export` for any call you want exported in your DLL! Also in IDA the list of the exports showed nothing... that was a huge f**ing clue. anyway the Windows version is verified to work now. Only thing is that a msvc140.dll might be necessary, but this is not a dexed problem. In this case people can just get it from the official microsoft website.
Re: Rationale for accepting DIP 1028 as is
On Friday, 29 May 2020 at 06:55:07 UTC, Robert M. Münch wrote: On 2020-05-27 06:59:28 +, Bruce Carneal said: Walter has confirmed that this is indeed the case. As you can read a few posts up his response to my "What am I missing?" query was "Nothing at all." Yes, it's really that bad. Will it be possible to see a report of these "greenwashed" call-chains, so that at least there is a chance to detect them? There was indeed activity on the "lets at least make this visible" front until Walter withdrew 1028 about 2 hours ago. The thread title in the Announce forum is: DIP 1028 "Make @safe the default" is dead
Re: Rationale for accepting DIP 1028 as is
On 2020-05-27 06:59:28 +, Bruce Carneal said: Walter has confirmed that this is indeed the case. As you can read a few posts up his response to my "What am I missing?" query was "Nothing at all." Yes, it's really that bad. Will it be possible to see a report of these "greenwashed" call-chains, so that at least there is a chance to detect them? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: DIP 1028 "Make @safe the Default" is dead
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.
