Re: iopipe v0.2.0 - safe update
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote: On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote: Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. Inside iopipe is a RefCounted type that is @safe. It uses the GC for memory management, so while destruction is synchronous, the memory itself is left to the GC to clean up. -Steve https://code.dlang.org/packages/iopipe What's iopipe and what does it do? How does it compare with std.process? Here's a pertinent dconf presentation that might help you: https://www.youtube.com/watch?v=un-bZdyumog The abstract: http://dconf.org/2017/talks/schveighoffer.html
Re: From the D Blog: A Pattern for Head-mutable Structures
On Friday, 26 June 2020 at 23:25:00 UTC, Dennis wrote: On Friday, 26 June 2020 at 19:57:36 UTC, Arun Chandrasekaran wrote: No, that's not right to say just for a hyperlink! Show some appreciation and kindness please. If we don't have anything nice to say, it's better not to say anything at all. True that! Mike has been doing many thankless jobs such as: - running the D blog - being in charge of the DIP process - maintaining BindBC C bindings - organizing DConf - managing bug bounties - helping people on the Learn forum and Discord - probably more I'm not aware of Instead of worrying about whether he should or shouldn't directly link to the HackerNews submission, let's take a moment to thank Mike for his work. Don't forget moderating the newsgroups! Heck, managing DIPs and their discussions alone is worthy of gratitude. So thank you, Mike.
Re: Hunt Framework 3.1.0 Released, Web Framework for DLang!
On Monday, 25 May 2020 at 19:59:57 UTC, Greatsam4sure wrote: On Monday, 25 May 2020 at 04:16:57 UTC, zoujiaqing wrote: On Friday, 22 May 2020 at 08:44:10 UTC, Greatsam4sure wrote: On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote: [...] A holistic tutorial will help this framework more. The docs are not helpful to me. This is the reason people use vibe because of the better docs, tutorial, and book Thanks watch Hunt Framework! There will be document output next month. It Will be good for the docs to be comprehensive. Tutorials are also highly needed Once the documentation is released, it'll be a lot easier for people other than the developers to create tutorials.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 19:44:00 UTC, Paul Backus wrote: On Monday, 25 May 2020 at 19:35:04 UTC, Clarice wrote: I really appreciate your contributions. (The latter of which will be quite handy.) But isn't the whole point of Walter's implementation of @safe-as-default is that FFIs are going to be assumed @safe? So they should still compile; that is unless you're referring to the need for re-evaluation. Yes, that's Walter's current plan. I am hoping that he'll change his mind about allowing un-annotated FFIs to be assumed @safe, but even if he doesn't, having the compiler print a warning will allow those of us who care about safety to find them and handle them properly. I'm still unsure which implementation is the right one, but I think this middle-ground you're attempting to get merged is a good compromise. So, again, thank you!
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 17:31:29 UTC, Paul Backus wrote: Even if you did review your code *and* all of your dependencies, if you did it before DIP 1028 was accepted (i.e., any time in the last 10 years or so), you may have deliberately left external @system functions un-annotated, because @system was the default. In fact, I *know* that people have done this, because I've been running my patched version of the compiler [1] against the dmd, druntime, and phobos codebases, and I have found an enormous number of such un-annotated declarations. Here are just a few of them in druntime: https://github.com/dlang/druntime/pull/3117 Lots and lots of projects in the D ecosystem are going to need similar patches to be compatible with DIP 1028. And I don't think it's realistic to expect people to make these changes without some kind of help from the tooling. [1] https://github.com/dlang/dmd/pull/11176 I really appreciate your contributions. (The latter of which will be quite handy.) But isn't the whole point of Walter's implementation of @safe-as-default is that FFIs are going to be assumed @safe? So they should still compile; that is unless you're referring to the need for re-evaluation.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 16:47:50 UTC, Paul Backus wrote: the compiler must warn D programmers that their declarations need to be reviewed for compatibility with @safe-by-default. Whether they were reviewed before that or not makes no difference. I'm not an engineer; I'm not learned in CS. So some clarification on this would be nice: if you're pulling in C code, or any code written in an unsafe language, wouldn't the developers doing such a thing already be aware they need to do their due diligence? Foreign code isn't just going to magically appear in your codebase, right? Maybe through dependencies, but one should check those too, eh? (And if the dependency tree is needlessly large, then the language has another, maybe bigger, problem à la the NPM ecosystem.)
