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. 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.)
Re: DIP 1028 "Make @safe the Default" is dead
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.
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 for listening to the community's feedback.
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. 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.
DIP 1028 "Make @safe the Default" is dead
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.
Re: Rationale for accepting DIP 1028 as is
On Thursday, 28 May 2020 at 12:28:16 UTC, Sebastiaan Koppe wrote: On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote: He did unfortunately manage to convince Atila, so the DIP has been accepted, but based on the discussions, I think that you may be the only person I've seen say anything positive about the DIP treating extern(C) functions as @safe. - Jonathan M Davis I think Walter had to make a tough call with many tradeoffs. The defining feature of engineering I would say. Is he wrong? Maybe, I don't know. The obvious path is far from always being a winner. A winner for what. The reasoning given doesn't make sense. Lots of people have pointed that out, and Walter has yet to expand on that. 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. That's worse. It'll cause huge breakage again if you need to convert extern(C) back to @system after it was converted to @safe. If @system by default proves to be a mistake, you can just flip it to @safe and it won't break any code. Why take a gamble on something that can't be rationalized?
Re: unit-threaded v1.0.0
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote: [snip] This last is sad, for me. I like using test functions rather than named unittest blocks. I recall playing with them when it was originally announced and thought they were quite nice, but I haven't used them since. The unit-threaded library certainly seems chocked full of features. Some of them overlap with the fluent-asserts library. It may make sense to split off some of that stuff as well so that people can evaluate custom assert libraries on their own merits. Similarly, the mocking and integration stuff could probably (?) be split off into separate packages. This would imply unit-threaded could be focused on the runner subpackage.
Re: unit-threaded v1.0.0
On Thu, 2020-05-28 at 15:35 +, Atila Neves via Digitalmars-d-announce wrote: > I decided to stop being like Google and finally tag version 1 of > unit-threaded: > > https://code.dlang.org/packages/unit-threaded > > From now on I'm going to focus on compilation speed (no matter > how ugly that might make the implementation), and also dropping > support in v2.x.x for anything other than unittest blocks (bye > bye test classes and functions). This last is sad, for me. I like using test functions rather than named unittest blocks. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Rationale for accepting DIP 1028 as is
Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe: > On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote: >> He did unfortunately manage to convince Atila, so the DIP has been >> accepted, but based on the discussions, I think that you may be the >> only person I've seen say anything positive about the DIP treating >> extern(C) functions as @safe. >> >> - Jonathan M Davis > > I think Walter had to make a tough call with many tradeoffs. The > defining feature of engineering I would say. > > Is he wrong? Maybe, I don't know. The obvious path is far from always > being a winner. > > 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. And this is going to be exactly the argument that will be used to dismiss any DIP trying to change the defaults later on. -- Johannes
Re: Rationale for accepting DIP 1028 as is
Am Thu, 28 May 2020 10:50:44 +0200 schrieb Daniel Kozak: > On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via > Digitalmars-d-announce wrote: >> >> As far as I can tell, Walter understands the issues but fundamentally >> disagrees with pretty much everyone else on the issue. > > I do not think so, the issue is, that there could be more people who > agree with Walter (like me), > but because we agree we do not participate. You can not really assume any opinion for people who did not participate, unless you can really prove why there's a bias. I did not participate either and I do not agree with Walter. So now we can say the opinions of those who did not participate in the discussion are split 50:50 ;-) We could assume there's a slight bias of those agreeing with Walter not responding because they don't have to actively convince anyone, as the DIP has been accepted. But given how much negative feedbcak there is, it's also likely people would voice their opinion to support the decision. Really the best thing we can assume is that the opionions of those not participating are split in the same way as the ones of those who are participating. The strawpoll posted recently suggests that as well: https://www.strawpoll.me/20184671/r -- Johannes
unit-threaded v1.0.0
I decided to stop being like Google and finally tag version 1 of unit-threaded: https://code.dlang.org/packages/unit-threaded From now on I'm going to focus on compilation speed (no matter how ugly that might make the implementation), and also dropping support in v2.x.x for anything other than unittest blocks (bye bye test classes and functions).
Re: Rationale for accepting DIP 1028 as is
On Thursday, 28 May 2020 at 02:47:01 UTC, Jonathan M Davis wrote: Walter has acknowledged the problem and seems to think that because it's the programmer's responsibility to deal with extern(C) functions correctly (since it's not possible for the compiler to do it), it's up to the programmer to go and fix any existing code that should be marked @system and isn't and that having the compiler incorrectly mark extern(C) declarations as @safe isn't a big problem, because programmers need to be spending the time to check them anyway. He's already created some PRs to try to fix some issues with extern(C) declarations in druntime and explicitly markingthem as @system but doesn't seem to think that it's ultimately a big deal. - Jonathan M Davis I've submitted a PR [1] to fix a whole bunch of these. It's currently blocked on what appear to be irrelevant CI failures (one of which is actually acknowledged as such in the discussion on Walter's PR). No one has given it any attention. Is there something I'm doing wrong? Should I be splitting my PR by file, to make it easier to review? I have a similar PR for Phobos in the works, and it would be nice to have some feedback on this so that one doesn't get ignored too. [1] https://github.com/dlang/druntime/pull/3117
Re: Rationale for accepting DIP 1028 as is
On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote: He did unfortunately manage to convince Atila, so the DIP has been accepted, but based on the discussions, I think that you may be the only person I've seen say anything positive about the DIP treating extern(C) functions as @safe. - Jonathan M Davis I think Walter had to make a tough call with many tradeoffs. The defining feature of engineering I would say. Is he wrong? Maybe, I don't know. The obvious path is far from always being a winner. 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.
Re: Rationale for accepting DIP 1028 as is
On Thu, May 28, 2020 at 03:21:09AM -0600, Jonathan M Davis via Digitalmars-d-announce wrote: [...] > With the DIP in its current state, @safe becomes a lie. The compiler > no longer guarantees that @safe code is memory safe so long as it > doesn't call any @trusted code where the programmer incorrectly marked > it as @trusted. Instead, the compiler blindly treats non-extern(D) > declarations as @safe and invisibly introduces memory safety bugs into > @safe code. Nothing about that is "OK." [...] I see it already. The next time someone wants to make a codebase @safe but the compiler complains about some violation, just add `extern(C)` to the function and move on. T -- Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine
Re: Rationale for accepting DIP 1028 as is
On 28.05.20 10:50, Daniel Kozak wrote: He seems to think that weakening @safe is worth doing, because it will ultimately mean that more code will be treated as @safe and mechnically checked by the compiler, And I believe he is right. No, it's a false dichotomy. Weakening @safe to allow more code to be @safe might have been sensible if there was no @trusted annotation. However, as things stand, @trusted is sufficient as a tool to introduce potentially wrong assumptions about memory safety, we don't need more, especially not implicit ones. The reason why people are not using @safe is partly that it is not the default, but it is mostly that their library dependencies _including Phobos_ are not properly annotated. This needs actual work to fix. If there is significant perceived value in performing @safety checks in @system code, we can add a new function attribute that causes non-transitive @safe checks but otherwise gets treated as @system. @safe does not have to take this role.
Re: Rationale for accepting DIP 1028 as is
On Thursday, May 28, 2020 2:50:44 AM MDT Daniel Kozak via Digitalmars-d- announce wrote: > On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via > > Digitalmars-d-announce wrote: > > As far as I can tell, Walter understands the issues but fundamentally > > disagrees with pretty much everyone else on the issue. > > I do not think so, the issue is, that there could be more people who > agree with Walter (like me), > but because we agree we do not participate. There may be some silent people who agree, but in all the discussions on this DIP, almost no one has agreed with Walter on this. It has not been a back and forth discussion with some on Walter's side and some against. It's been pretty much everyone against Walter. He did unfortunately manage to convince Atila, so the DIP has been accepted, but based on the discussions, I think that you may be the only person I've seen say anything positive about the DIP treating extern(C) functions as @safe. The fact that @safe becomes the default has garned some debate with some in favor and some against (with most seeming to be in favor), but the idea of making extern(C) declarations @safe by default has been almost universally considered a bad idea by anyone who has responded on the topic. Most DIPs do not get anywhere close to this level of negative feedback. > > But since Walter managed to convince Atila, the DIP has been accepted. > > So everything is OK right? Everything is okay? Because a bad DIP got accepted? No, most definitely not. Quite the opposite. With the DIP in its current state, @safe becomes a lie. The compiler no longer guarantees that @safe code is memory safe so long as it doesn't call any @trusted code where the programmer incorrectly marked it as @trusted. Instead, the compiler blindly treats non-extern(D) declarations as @safe and invisibly introduces memory safety bugs into @safe code. Nothing about that is "OK." From the way things currently look, we're going to have to deal with that hole in @safe in D code in the future, because the DIP has been accepted, but it adds yet another dark corner to the language of the sort that folks here tend to make fun of C++ for. Going forward, we're going to have to be explaining to people why @safe code doesn't actually guarantee that code is memory safe (in spite of the fact that that's what it claims to do) and why any and all non-extern(D) declarations have to be treated with extreme caution to avoid invisibly introducing memory safety bugs into your code. Walter is very intelligent and has made many great decisions with D, but IMHO, this is definitely not one of them. - Jonathan M Davis
Re: Rationale for accepting DIP 1028 as is
On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via Digitalmars-d-announce wrote: > > As far as I can tell, Walter understands the issues but fundamentally > disagrees with pretty much everyone else on the issue. I do not think so, the issue is, that there could be more people who agree with Walter (like me), but because we agree we do not participate. > He seems to think > that weakening @safe is worth doing, because it will ultimately mean that > more code will be treated as @safe and mechnically checked by the compiler, And I believe he is right. > whereas most everyone else thinks that weakening @safe is unacceptable. You make bad assumptions, who is "most everyone else"? I have only see few members of dlang arguing about that. But there is much bigger community around there. > But since Walter managed to convince Atila, the DIP has been accepted. > > - Jonathan M Davis > So everything is OK right?
