Re: DIP1028 - Rationale for accepting as is

On Fri, May 22, 2020 at 10:50:02PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 5/22/2020 10:33 AM, rikki cattermole wrote: > > To me at least, this butchers @safe/trusted/system into a system > > that is near useless for guarantees for an entire program. > > It never attempted to

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. Meant: blindly making the wrappers, without thinking whether calling the wrapper would always be `@safe`

Re: DIP 1028--Make @safe the Default--Formal Assessment

On 2020-05-22 03:16, Walter Bright wrote: The level of negativity in that thread was what caused me to stop responding, though I continued reading. Every reply I made produced 10 responses, an exponential explosion, and yet I was just repeating myself. Two sides to every story. FWIW, I am

Re: DIP1028 - Rationale for accepting as is

On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote: Am I saying nothing bad can happen if we implicitly trust extern(C) declarations? No. I'm saying we'll be no worse off if they're all implicitly @system. This compiles with no warnings right *now*: void main() { import

Re: DIP1028 - Rationale for accepting as is

On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote: memcpy isn't a good example since it's explicitly @system Yes, it's a good example. Because if you include any C function, you don't know if it uses memcpy internally - except if you have the code. And as memcpy is used heavily

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign

Work = Resources * Efficiency

Work = Resources * Efficiency Applicable to IT, CS, and any other form of engineering. Just putting that out there, FWIW. Sources: - "Efficiency": Merriam-Webster : 1: the quality or degree

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: The more I think of Atila's and Walter's responses, the more they are starting to make sense. [snip] In fact this former antipattern means that it'd make sense to have an inverse of `@trusted` attribute, lets say `@suspect`. It would

Re: DIP1028 - Rationale for accepting as is

On 5/22/20 8:05 PM, Walter Bright wrote: On 5/22/2020 10:54 AM, Atila Neves wrote: BTW, you should fix that invalid attribute, freeing a pointer is never @safe unless you can guarantee nobody else has a copy of that pointer (and considering it's passed by value, the CALLER still has that

Re: DIP1028 - Rationale for accepting as is

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote: [..] Yes, there's a cost, which is carefully vetting extern(C) and extern(C++) declarations. The decision came down to finding this an acceptable trade-off. How would you feel about a DIP that the only thing it did was assume all

Re: DIP1028 - Rationale for accepting as is

The more I think of Atila's and Walter's responses, the more they are starting to make sense. When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to

Re: DIP1028 - Rationale for accepting as is

On 5/23/20 6:55 AM, Dukc wrote: The more I think of Atila's and Walter's responses, the more they are starting to make sense. When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the

Re: Work = Resources * Efficiency

On Sat, May 23, 2020 at 04:00:35AM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: [...] > "Efficiency": Merriam-Webster > : > > 1: the quality or degree of being efficient ("X is X! Yawn, tell me > something that means

Re: DIP 1028--Make @safe the Default--Formal Assessment

On 5/21/20 7:49 PM, Bruce Carneal wrote: 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 $$$

Re: DIP1028 - Rationale for accepting as is

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote: [..] Yes, there's a cost, which is carefully vetting extern(C) and extern(C++) declarations. The decision came down to finding this an acceptable trade-off. How would you feel about a DIP that the only thing it did was make all

Codefence, an embeddable interactive code editor, has added D support.

Hi everyone, as the subject states, you can find it here, https://codefence.io/ The current version is 2.092.0 with dmd. Regards,

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 12:13:45 UTC, Steven Schveighoffer wrote: What is not fine is having the compiler do it for you so nary a @trusted marking is in sight. I don't really understand the draw of that. -Steve I think not only about how @safe mechanically verifiable is an advantage,

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

On Saturday, 23 May 2020 at 04:07:35 UTC, Mike Parker wrote: I suggest you create project/lib and drop the SDL libraries there along with the bindbc-sdl library and pass the path to the linker. Since you should be using the MS linker (see below), it expects the /LIBPATH option

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

On Saturday, 23 May 2020 at 03:55:33 UTC, Mike Parker wrote: On Saturday, 23 May 2020 at 03:25:12 UTC, Daniel C wrote: This is what I'm getting: Error 42: Symbol Undefined __D6bindbc3sdl4bind9sdlevents9SDL_Event6__initZ This isn't a symbol from the SDL library. It's a D symbol from the

Re: DIP1028 - Rationale for accepting as is

On 23/5/20 20:40, Johannes T wrote: 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. [..] Thank you for the detailed and insightful explanation. Would it be feasible to have a follow-up DIP that

Re: Codefence, an embeddable interactive code editor, has added D support.

On Saturday, 23 May 2020 at 19:49:33 UTC, welkam wrote: On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote: Hi everyone, as the subject states, you can find it here, https://codefence.io/ The current version is 2.092.0 with dmd. Regards, Why such thing is free? Who pays for the

Re: Codefence, an embeddable interactive code editor, has added D support.

On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote: Hi everyone, as the subject states, you can find it here, https://codefence.io/ The current version is 2.092.0 with dmd. Regards, Why such thing is free? Who pays for the servers?

Re: DIP1028 - Rationale for accepting as is

On 23.05.20 21:46, Arafel wrote: Now it has to be clearly explained that you should check for @trusted code AND unmarked external C functions. ... and @system static constructors and `--boundscheck=off` and initializers of globals

Re: Codefence, an embeddable interactive code editor, has added D support.

On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote: Hi everyone, as the subject states, you can find it here, https://codefence.io/ The current version is 2.092.0 with dmd. Regards, Nice. Very useful. Imagine something like this for the D blog

Re: DIP1028 - Rationale for accepting as is

On Sat, May 23, 2020 at 10:55:40AM +, Dukc via Digitalmars-d-announce wrote: [...] > When I look my own code that uses the Nuklear GUI library, written in > C, it's all `@system`. I have not had the time to make `@trusted` > wrappers over the BindBC-nuklear API, so I did what tends to occur to

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 15:33:05 UTC, H. S. Teoh wrote: On Sat, May 23, 2020 at 10:55:40AM + And this is precisely why I proposed that what we need is a way for the compiler to mechanically check all code *except* certain specified blackboxes that are skipped over. Then you can have

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. [..] Thank you for the detailed and insightful explanation. Would it be feasible to have a follow-up DIP that enables implicit @system extern as

Re: DIP1028 - Rationale for accepting as is

On 24/5/20 0:02, ag0aep6g wrote: ... and @system static constructors and `--boundscheck=off` and initializers of globals Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe

Re: DIP 1028--Make @safe the Default--Formal Assessment

On 5/23/2020 4:26 AM, Faux Amis wrote: Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful? I would definitely listen/watch; even if I were muted and could only chat maybe. You're right, and that is the whole

Re: DIP1028 - Rationale for accepting as is

On 24.05.20 00:17, Arafel wrote: On 24/5/20 0:02, ag0aep6g wrote: ... and @system static constructors and `--boundscheck=off` and initializers of globals Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without

Re: DIP1028 - Rationale for accepting as is

On Saturday, 23 May 2020 at 22:38:58 UTC, ag0aep6g wrote: On 24.05.20 00:17, Arafel wrote: On 24/5/20 0:02, ag0aep6g wrote: ... and @system static constructors and `--boundscheck=off` and initializers of globals Other than `--boundscheck=off`, that is presumably actively chosen by the

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote: I'll be mucking around with it again later. Well, I'm having limited success. I got 32-bit compile/run using basic -m32, and -m64 compiles but crashes lol. Trying out 32-bit -m32mscoff with Microsoft Build Tools (2019) resulted in

Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

On Sunday, 24 May 2020 at 04:16:10 UTC, Daniel C wrote: On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote: I'll be mucking around with it again later. Well, I'm having limited success. I got 32-bit compile/run using basic -m32, and -m64 compiles but crashes lol. Trying out 32-bit

Re: DIP 1028--Make @safe the Default--Formal Assessment

On 23.05.20 17:07, Andrei Alexandrescu wrote: A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead.

Re: DIP 1028--Make @safe the Default--Formal Assessment

On 5/23/20 6:49 PM, ag0aep6g wrote: On 23.05.20 17:07, Andrei Alexandrescu wrote: A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise

Re: DIP1028 - Rationale for accepting as is

On 24.05.20 02:55, Arine wrote: That works even if you make the static this() @safe, and remove the pointer incrementation. Sure. `*p = 13;` is perfectly @safe. The static constructor isn't needed for that part. You can just as well do the assignment in `main`. The static constructor is

Re: DIP1028 - Rationale for accepting as is

On 24/5/20 0:38, ag0aep6g wrote: On 24.05.20 00:17, Arafel wrote: On 24/5/20 0:02, ag0aep6g wrote: ... and @system static constructors and `--boundscheck=off` and initializers of globals Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would

Re: DIP 1028--Make @safe the Default--Formal Assessment

On Saturday, 23 May 2020 at 15:07:16 UTC, Andrei Alexandrescu wrote: On 5/21/20 7:49 PM, Bruce Carneal wrote: 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

Re: DIP1028 - Rationale for accepting as is

On 5/22/2020 10:25 AM, Timon Gehr wrote: With the o/b system `free` might actually work out OK free(new int); I did mention in the documentation that when using different memory allocators, mixing them up will not be detected. You'd have to declare the allocators using specific pointer

Re: DIP1028 - Rationale for accepting as is

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. 2. If un-annotated declarations cause a compile time error, it is highly

Re: DIP1028 - Rationale for accepting as is

On 24.05.20 05:28, Walter Bright wrote: I'd like to emphasize: I understand all of those points and most of them are true, and obvious. The issue is that they are not a justification for the decision. You seem to think that greenwashing is not greenwashing when it is done by the compiler