Re: DConf '23 August 29th - September 1 --- Early-Bird Registration is Open!
On Saturday, 25 March 2023 at 09:46:08 UTC, Mike Parker wrote: It's official: DConf '23 is locked in at CodeNode in London, August 29th - September 1st. And early-bird registration is open! https://dconf.org/2023/index.html From the link above, first sentence: Join us at CodeNode in London once again from August 1–4, 2023, for the D Programming Language Conference, ... I assume the correct dates are August 29th - September 1st? I'm very much looking forward to DConf, to conversing with at least some of my online D acquaintances in person. I hope that many of you can come.
Re: GDC documentation is online and 13.x development updates.
On Tuesday, 6 December 2022 at 12:13:59 UTC, Iain Buclaw wrote: Hi, There is now (long overdue) expanded documentation of the user-facing features of GDC online on GCC's documentation site. ... This is very much appreciated, especially the SIMD portion. Thanks.
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 00:32:33 UTC, Ali Çehreli wrote: On 5/8/22 17:25, H. S. Teoh wrote: > somebody should make a dmd > fork that introduces write barriers, plus a generational GC (even if > it's a toy, proof-of-concept-only implementation) to see if the > performance hit is really as bad as believed to be. Ooh! DConf is getting even more interesting. :o) Ali A helpful paper: "Getting to Go: The Journey of Go's garbage collector". Positive highlights: 1) non-copying 2) no read barriers Less friendly: 1) write barriers 2) GC aware fiber scheduler 3) other??? Would be some (huge amount?) of work but porting/enabling an opt-in golang latency GC could be a big enabler for the casual/soft "real time" crowd. Here's a link to the paper: https://go.dev/blog/ismmkeynote
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
Well done Paul. I appreciate the clarity, simplicity and utility.
Re: Idioms for the D programming language
On Sunday, 14 February 2021 at 17:56:00 UTC, James Lu wrote: On Saturday, 13 February 2021 at 16:39:12 UTC, Imperatorn wrote: On Saturday, 13 February 2021 at 16:06:31 UTC, James Lu wrote: [...] "readable by a beginner" && "interesting and substantial information" might be hard to find. Did you mean front- or backend? If you want to show compiler u might look at https://github.com/dlang/dmd/blob/master/src/dmd/compiler.d for example. Frontend, to show the language. If you are looking for high level understanding of a D front end https://github.com/SDC-Developers/SDC might help, either standalone or as a supplement to your DMD readings. On the minus side, SDC is a hibernating prototype. On the plus side, SDC employs a strong architecture that factors out many of the dependency issues facing DMD. What remains is very readable.
Re: sumtype 0.10.0: multiple dispatch
On Thursday, 24 September 2020 at 02:28:11 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is designed to be an improved alternative to `std.variant.Algebraic`. [...] Sure looks like a strong advance. Hope it sees a lot of use.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Saturday, 8 August 2020 at 22:13:57 UTC, Bruce Carneal wrote: Per the original post in this thread, the current compiler doesn't convert decimal floating point literals to binary form correctly in all normal cases. Assuming people actually want to be correct/consistent to the last bit wherever possible, that should change. Additionally, the default library conversions should match those of the compiler. They should also be correct/consistent. This could be accomplished by introducing Mir dependencies in a few places but I think fully accredited copying is a better way to go. There is more to maintain, true, but accurate conversion is fundamental in nature. We're not talking about some high level library here. Hard to get right? Apparently. Esoteric? No. As to timing, if the subnormal update Ilya mentioned is very close it would make sense to wait for that version. Side note: the truly persnickety/paranoid might favor hex floating point literals but those are pretty hard on human readers. At least the conversion implementations should not require heroics. OTOH, this is pretty small potatoes when compared to other CTFE floating point discrepancies (no control of precision, all to 'real' IIUC). Maybe the best that can be done is to align the library with better practice.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Saturday, 8 August 2020 at 18:16:30 UTC, Avrina wrote: On Friday, 7 August 2020 at 13:24:36 UTC, Andrei Alexandrescu wrote: On 7/7/20 8:04 AM, Steven Schveighoffer wrote: On 7/7/20 7:13 AM, 9il wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote: On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote: FWIW it would be wisest to simply copy the code from Mir into druntime now with due credit. It's a minimally committal decision than can be easily revisited later. It is legal, appropriate, and there's no shame to it any more than it is for other projects to fork (parts of) dmd, druntime, or phobos. What's the purpose of that? If someone needs Mir, they can just add it as a dependency in dub. This will just be adding more bloat to drubtime. The development surrounding D seems to have a stigma of using external dependencies even when there is significant benefit. I find it odd that you bring up that there's no shame to copy and paste. It seems the only reason there simply wouldn't be a link to a dependency is because of stigma. There's no shame relying on another project and you don't have to copy and paste it. Optlink, DMC, DMC's club, etc. Its gotten better than it was, but there's no reason to even use any of those anymore, supporting them is just a waste of time. As would maintaining a copy pasta of Mir would be. Per the original post in this thread, the current compiler doesn't convert decimal floating point literals to binary form correctly in all normal cases. Assuming people actually want to be correct/consistent to the last bit wherever possible, that should change. Additionally, the default library conversions should match those of the compiler. They should also be correct/consistent. This could be accomplished by introducing Mir dependencies in a few places but I think fully accredited copying is a better way to go. There is more to maintain, true, but accurate conversion is fundamental in nature. We're not talking about some high level library here. Hard to get right? Apparently. Esoteric? No. As to timing, if the subnormal update Ilya mentioned is very close it would make sense to wait for that version. Side note: the truly persnickety/paranoid might favor hex floating point literals but those are pretty hard on human readers. At least the conversion implementations should not require heroics.
Re: The ABC's of Templates in D
On Friday, 31 July 2020 at 13:46:43 UTC, Mike Parker wrote: I'm planning to publish several articles and tutorials about D templates over the next few months. As a means of setting the stage, I've published this tutorial on the basics. The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ Good writing for the not-quite-beginner-and-up audience Mike. Reading it reminded me of how much I had been taking for granted, of how much power D provides with minimal drag. Really hope I never have to go back to C++/CUDA. Also enjoying your book. Looking forward to additional blog posts.
Re: Origins of the D Programming Language now published by ACM!
On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote: https://dl.acm.org/doi/abs/10.1145/3386323 Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours spent fixing the mess I originally wrote. Great read. Many thanks for the time spent writing out the origin story of a wonderful language.
Re: DIP 1028 "Make @safe the Default" is dead
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".
Re: DIP 1028 "Make @safe the Default" is dead
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.
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: 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: 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.
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.
Re: DIP1028 - Rationale for accepting as is
On Thursday, 28 May 2020 at 02:39:40 UTC, Jonathan M Davis wrote: On Wednesday, May 27, 2020 8:13:52 PM MDT Bruce Carneal via Digitalmars-d- announce wrote: On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis wrote: > [...] I remember reading a suggestion that additional linker symbols be emitted to carry the attribute and possibly type information while leaving the ABI untouched. Was this found to be impractical? Steven suggested something along those lines. I don't know how practical it would or wouldn't be, but I don't think that Walter even responded to the idea. Changing the DIP process to be 2 of 3 LMs required for acceptance could get us past all the "this is useless because Walter xyz..." road blocks. I've a proposal in to Mike for that now. We'll see how it goes. [snip] But regardless of whether DIP 1028 is the correct decision, the problem remains that your typical extern(C) function cannot be checked for @safety by the compiler, because it was compiled by a C compiler. The question then is just how the D compiler should treat them, and that's the main point of contention. There may be solutions like Steven suggested which would deal with edge cases where the implementation is in D but the linkage isn't, but ultimately, they're just edge cases. - Jonathan M Davis Yes. I understand the practical limits of machine checking and the 1028 issues. The edge case that I had in mind was piece wise replacement of C libraries with dlang reworkings and LCD FFI libraries written in dlang for Python and other languages. With the symbol additions, ABI could be decoupled from D-specific capabilities. Python and other C FFIs just work. Dlang programs get broader guarantees. Still, as you say, probably not a big concern.
Re: DIP1028 - Rationale for accepting as is
On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis wrote: On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via Digitalmars-d- announce wrote: [...] Except that the linker matters a great deal in this discussion with regards to extern(D) functions, because @safe and @trusted are part of the name mangling for extern(D) functions. That means that if an extern(D) function declaration's attributes do not match its definition, then you'll get a linker error. So, treating non-extern(D) function declarations as @safe by default isn't necessarily a problem (though it would certainly work to just treat all function declarations as @system by default rather than treating extern(D) function declarations differently). The cases where non-extern(D) function declarations weren't actually @safe would be caught during the linking process. Sure, it would be nice if it were caught sooner, but you don't end up with them being invisibly treated @safe when they're not like we're going to get with DIP 1028. [...] I remember reading a suggestion that additional linker symbols be emitted to carry the attribute and possibly type information while leaving the ABI untouched. Was this found to be impractical?
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[big snip of very long and arguably tangential Java screw-up and
other]
How does this relate to safe by default?
Consider the common (because that's how D started out) case of:
- clibrary.d
T massage_data(... many parameters ...);
... 200 more such declarations ...
- app.d --
import clibrary;
void useClibrary( ... parameters ...) {
massage_data(parameters);
}
-
This code, today, does not use annotations and it works. It's
been working
for a long time. Now, we implement the amendment, and it stops
compiling
because useClibrary is @safe and massage_data is @system. The
user is faced
with the following alternatives:
1. Go through 200 functions in clibrary.d and determine which
are @safe
and which are @system. This is what we want them to do. We try
to motivate
this with compiler error messages. Unfortunately, this is both
tedious and
thoroughly impractical, as our poor user Will Not Know which
are safe and
which are system. We can correctly annotate core.stdc.stdio
because I know
those functions intimately. This is not true for other system C
APIs, and
even less true for some third party C library we're trying to
interface to.
So, to condense and hopefully clarify: we can not use option 1)
and @system by default because "our poor user Will Not Know which
are safe and which are system"?
IOW, because someone unable to comment on safety would be
inconvenienced we enable them to inject more code into the
ecosphere by making @safe the default.
What am I missing?
2. Annotate useClibrary() as @trusted or @system. While easier,
this causes
all benefits to @safe by default to be lost.
3. Wrap the call to massage_data() with:
() @trusted { massage_data(parameters); } ();
If there are a lot of calls to clibrary, this is going to look
pretty awful.
Nobody likes writing or reading such ugly code. It's ok here
and there, but
not as a general thing.
4. Edit clibrary.d and make the first line:
@safe:
[snip regarding greenwashing and other]
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 13:50:25 UTC, Bruce Carneal wrote: On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote: [...] You continue to miss the point. Additionally, there never was any "working legacy code". As established, the pre 1080 compiler would have rejected the code. Does-not-compile != working-code. pre 1028 compiler
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote: On 5/27/2020 2:34 AM, Bastiaan Veelo wrote: On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote: On 5/26/2020 11:20 PM, Bruce Carneal wrote: I'm not at all concerned with legacy non-compiling code of this nature. Apparently you agree it is not an actual problem. Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me. His argument was: "Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing?" I replied that it was unlikely that such legacy code existed. He replied that he was not concerned about it. I.e. working legacy code is not going break. You continue to miss the point. Additionally, there never was any "working legacy code". As established, the pre 1080 compiler would have rejected the code. Does-not-compile != working-code.
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 02:58:16 UTC, Andrei Alexandrescu wrote: On 5/26/20 12:31 PM, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? If that's the case, it's the death of DIP 1028. 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. Your help in undoing this mistake would be greatly appreciated by me and by the authors of, literally, hundreds of posts in this thread opposing the DIP.
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote: On 5/26/2020 9:31 AM, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? Nothing at all. But I doubt there is much legacy non-compiling code around. The intent of my above was to illustrate the difference between pre 1028 compiler behavior and post 1028 compiler behavior. I'm not at all concerned with legacy non-compiling code of this nature. I am concerned about the change in compiler behavior. As you've confirmed, post 1028 the compiler will accept an @safe routine calling in to an un-annotated extern C function without complaint. Andre, I hope this is clear enough for you.
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 20:38:17 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? I agree that being forced to think about a trusted interface to that routine can contribute to safety. Not getting this is the price if DIP 1028 as is. Doing it the other way bears a different price. Still, it does not change the amount of code that must be vetted during an audit, either way. If you pick up 100% of the code that the post 1028 compiler lied about, then I agree. Unsafe is unsafe even if your compiler stays mum. If you pick up less than 100%, I disagree. In that situation the compiler will have "helped" you to reduce the amount of code to be audited. And finally, were the 1028 extern!(D) default changed to @system, I disagree. The amount of code in non-greenwashed @trusted wrappers should be smaller. (note that I discount the one time audit of stable @system libraries)
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 18:06:00 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: @safe: the compiler checks The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check. Completely agree but my above says nothing about @trusted. But it matters. Even if your code is @safe, that doesn't mean it is completely safe. Your @safe code can call into somebody else's @safe code that can call @trusted code that calls @system code. If you want to guarantee that your code is safe, you'll have to find and audit the @trusted bits (as well as everything that is called from there). Agree that the transitive closure is difficult, especially for humans. If extern(C) is implicitly @system, you'll have to make calls @trusted and they are subject to auditing. If extern(C) is implicitly @safe, calls are still subject to auditing. Whatever your preference, I think the compiler can be of greater help in finding the bits that require auditing than grep can, and then the difference isn't all that important anymore. Safe wrappers around C libraries are still written the same way, audited the same way, and unsafe calls into C caught the same way. Agree. @trusted doesn't mean that the code so labelled should be blindly trusted. The aim should be reduction of @trusted where practical. Silently letting all extern C functions inside the tent is not a reduction. I agree that making extern(!D) @system looks sound, like the way it should be. But it breaks compilation of existing code, and it is too easy to evade by slapping on an explicit @trusted or (God forbid) @safe. Or we could make extern(!D) to be anything other than @system an error, which would be really annoying. I think that what we all strive for is to reduce the strain of coding as well as to reduce the strain of auditing. I'm all for reducing the strain of writing correct code. As others have implied, we're dealing with, at least, two issues here: 1) any transition from opt-in to opt-out safety will break code. Some programmers will resort to greenwashing in an effort to "fix" it. Will we be better off post transition? And 2) should uncheckable code be considered @safe, ever.
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote: On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: [...] The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.j Completely agree but my above says nothing about @trusted. [...] The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits. Another distinction: pre 1028 your compilation will error out. Post 1028 it will not. Quite the opposite. Most code out there isn't marked as @safe/@trusted/@system. If I add a dub dependency and don't bother with @safe, I can call anything, in any way. Post 1028... nope. Unmarked @system function definitions themselves won't compile. I think I see the difficulty. We both support 1028's elimination of the "I can call anything, in any way" default. I really like @safe by default for machine checkable code. I don't support @safe by default for extern C.
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote: On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: [...] Completely agree but my above says nothing about @trusted. [...] Another distinction: pre 1028 your compilation will error out. Post 1028 it will not. Quite the opposite. Most code out there isn't marked as @safe/@trusted/@system. If I add a dub dependency and don't bother with @safe, I can call anything, in any way. Post 1028... nope. Unmarked @system function definitions themselves won't compile. Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing?
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: @safe: the compiler checks The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.j Completely agree but my above says nothing about @trusted. @safe post 1028: the compiler checks, sometimes, just not in the scary parts The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits. Another distinction: pre 1028 your compilation will error out. Post 1028 it will not.
Re: Safety audit and the overlooked emergency exit
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: [snipped an outline of tooling to mitigate 1028 damage] I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe. Yes. Tooling is good and will be much appreciated if 1028 stands. Reducing the need for tooling is even better. @safe: the compiler checks @safe post 1028: the compiler checks, sometimes, just not in the scary parts
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 12:51:59 UTC, Atila Neves wrote: On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote: On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote: [...] If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true. -preview=safe now -revert=safe "tomorrow" If these are permanent, an ugly fork will have occurred in all but name. If these are temporary, we'll have gained little since the damage caused by assuming human checked routines are @safe will remain after the switches are removed.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote: On 5/25/2020 7:04 PM, Johannes Loher wrote: Now let's compare the two different options: 1. With DIP1028 in its current form, the code will compile and a memory corruption will actually happen. The problem might be extremely difficult to track down for the developer because he has no clues whatsoever where to start looking. 2. With one of the solutions that were presented, the code will not compile as it is. According to your argument of „convenience“, the developer will probably just mark the function incorrectly as @trusted which makes the code compile. The memory corruption will happen. However, even if the developer did not think much about potential safety issues when adding @trusted to the function, he now still remembers that he did that (it was a conscious decision, even if it was a careless and lazy one). He has a clear point to start looking for the reason of the memory corruption. Do you honestly think option 1 is better? Yes, for reasons I carefully laid out. A direct response to Andre's thorough critique of your reasoning would be appreciated. > no clues whatsoever He can look at unattributed declarations. Again, as many have noted, putting a coverage problem like this on the programmer is problematic. The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts. Greenwashing is bad. En masse greenwashing by the compiler, as mandated by the DIP currently, is really bad.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 01:04:24 UTC, Timon Gehr wrote: On 24.05.20 11:10, Walter Bright wrote: On 5/23/2020 11:26 PM, Bruce Carneal wrote: I don't believe that you or any other competent programmer greenwashes safety critical code. Regardless, the safety conscious must review their dependencies whatever default applies. That's the theory. But we do, for various reasons. I've seen it a lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way. We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly. Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing. Yes, it would be a big nuisance. Absent a change in the DIP the safety conscious who want to continue with D will try to back out the compiler lies as best they can: additional tooling, additional code review strictures, selective rewrites, ... Not sure how that unfortunate future would play out exactly but it would not be pretty. Much much better to fix the DIP.
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 06:26:56 UTC, Bruce Carneal wrote: On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote: [snip] 3. Un-annotated declarations are easily detectable in a code review. Automating this for the transitive closure of defaulted @safe functions would help. Maybe that capability is there already and I missed it? This tooling up to try and mitigate the damage caused by the DIP would not be necessary were Timon's model followed. After reading Timon's latest I've regained hope that this could still work out well.
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote: I'd like to emphasize: 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe. Agree completely. Not in dispute that I've seen. In the same vein, defaulting a declaration to @safe doesn't make it safe. For the ultra paranoid, even the name mangling in D libraries is not to be trusted because "the implementation is not available". 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. I don't believe that you or any other competent programmer greenwashes safety critical code. Regardless, the safety conscious must review their dependencies whatever default applies. 3. Un-annotated declarations are easily detectable in a code review. Automating this for the transitive closure of defaulted @safe functions would help. Maybe that capability is there already and I missed it? [snip] It is, in a not-at-all obvious way, safer for C declarations to default to being safe. I agree that it is not-at-all obvious. On a positive note, the DIP discussion/clarification should encourage the safety conscious to rebase code to a machine checkable form whenever feasible.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote: I think the source of the problem is that Walter's DIPs require the community to prove that Walter's proposal is so bad that he needs to reject it. Anyone else's proposal has to prove that it's worthy of being added to the language. There's a big perceived gap between those two. As I've said many times, it's odd for someone to judge his own DIPs, ... When either Walter or Atila author a DIP, their spot in the "convince both or face rejection" duopoly could be taken by another person.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote: On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote: As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now. And again why waste time with this process plus 2 rounds of discussion? I mean just do it and tell in this announcement section about the feature. The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process. It's intended to elicit community feedback to enhance the DIP under review (the Feedback Threead) and to allow the airing of opinions (the Discussion Thread). All DIP authors have the freedom to incorporate suggestions into their DIP or not, and Walter and Atila make the decision to accept or reject. If you look at the history of Walter's DIPs, they *do* take the opinions into consideration even when he is the author. Several of his previous DIPs have been withdrawn or rejected. No dispute here. If a popular DIP is rejected, it means neither of them were convinced by opinion to accept it. And, as in the case for this DIP, if an unpopular DIP is accepted, it means they were not persuaded by the arguments against it. Not exactly. IIUC logical "and" is required for approval. One of the two might have been persuaded to accept. "not and", a single disapproval, suffices for rejection. I believe this is a useful weighting. From my perspective, the process is working as intended, despite the comments to the contrary in this thread. You either convince a DIP author to modify his DIP, or you don't. You either persuade Walter and Atila to accept or reject it, or you don't. Again, IIUC, you either persuade Walter *or* Atila to reject or you don't. Apropos of which, what does Atila think of this DIP?
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
of material indicating, among other things, that even
really good programmers can screw up when it comes to language
design now and then. Ahem.
Continuing...
How does this relate to safe by default?
Consider the common (because that's how D started out) case of:
- clibrary.d
T massage_data(... many parameters ...);
... 200 more such declarations ...
- app.d --
import clibrary;
void useClibrary( ... parameters ...) {
massage_data(parameters);
}
-
This code, today, does not use annotations and it works. It's
been working
for a long time. Now, we implement the amendment, and it stops
compiling
because useClibrary is @safe and massage_data is @system. The
user is faced
with the following alternatives:
1. Go through 200 functions in clibrary.d and determine which
are @safe
and which are @system. This is what we want them to do. We try
to motivate
this with compiler error messages. Unfortunately, this is both
tedious and
thoroughly impractical, as our poor user Will Not Know which
are safe and
which are system. We can correctly annotate core.stdc.stdio
because I know
those functions intimately. This is not true for other system C
APIs, and
even less true for some third party C library we're trying to
interface to.
Agree completely. Annotating C code correctly can be very
difficult. This argues against defaulting such code to @safe.
2. Annotate useClibrary() as @trusted or @system. While easier,
this causes
all benefits to @safe by default to be lost.
No. The benefit of @safe is actually having machine checkable
@safety.
3. Wrap the call to massage_data() with:
() @trusted { massage_data(parameters); } ();
If there are a lot of calls to clibrary, this is going to look
pretty awful.
Nobody likes writing or reading such ugly code. It's ok here
and there, but
not as a general thing.
Yeah, this is ugly.
4. Edit clibrary.d and make the first line:
@safe:
I submit that, just like with Java, Option 4 is what people
will reach for,
nearly every time. I've had some private conversations where
people admitted
this was what they'd do. People who knew it was wrong to do
that.
The DIP gives us 4), the worst case, by default. Anywhere and
everywhere a C lib shows up it gives us 4), automatically.
If it's @safe by default, and then someone chooses to annotate
it with @system
here and there, I'd feel a lot more confident about the
accuracy of the code
annotations than if it just had @safe: at the top. At least
they tried.
So @safe is to be based on a feeling? At least they *tried*?
This is a key point of disagreement. Machine checked @safety is
something. Human hand waving @safety is not.
It is bizarre that no one has been able to get you to see the
contradiction with your earlier writings on safety (big fan there
btw). C's biggest blunder? Yeah, well, all the bugs engendered
by that blunder and many many more are now to be considered @safe
by default. What the heck?
Finally, Atila, can you shed any light on this? Where do you
stand? Why did it seem like a good idea to withhold your veto?
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time?
