Dlang club meeting tonight at 7
https://x.com/WalterBright/status/1781022970984775915
Re: Upcoming ACCU 2024 Talk: How DLang Improves my Modern C++ and Vice Versa
On 4/7/2024 6:38 PM, Mike Shah wrote: I'll be talking more about D (and modern C++) at the ACCU 2024 conference in Bristol (Abstract below -- talk is on April 19, 2024). Let me know if you'll be joining (in-person or online)! The recording of the talk will otherwise be posted after the talk, and slides will immediately be available on my website after the talk is given. https://accuconference.org/session/how-dlang-improves-my-modern-cpp-and-vice-versa ABSTRACT: The D programming language (DLang) is a multi-paradigm language (like C++) developed to solve real software engineering problems. DLang has a rich history since its inception in 2001, and continues to be an actively evolving memory-safe language used in industry. In this talk, I will discuss how learning and using the D language has directly benefited my use and learning of C++ and vice versa. We'll look at the evolution of both C++ and Dlang, and see how each language has borrowed from each other during their most recent evolution in the past decade. Throughout the talk, I will provide side-by-side code comparisons showing idiomatic ways to complete tasks in D alongside C++ code examples. The goal of this talk however is not to pit one language against the other, but rather to show how to use each language to its strengths and learn how to become a better programmer. Audience members are expected to be familiar with Modern C++, but are not expected to have any prior D programming experience. Wow! Talking at ACCU is an honor. I'm so pleased you're doing this!
Re: Bug fixes for Mac OSX landing in 2.107.1
Wow! This is really good work. It's much appreciated!
Re: Dlang meeting tonight at the Overlake Red Robin at 7pm
On 2/23/2024 4:54 PM, Walter Bright wrote: Tonight's agenda: select the Ring Bearer. Those who don't show up run the risk of being chosen. We had our largest ever group, 8 people!
Dlang meeting tonight at the Overlake Red Robin at 7pm
Tonight's agenda: select the Ring Bearer. Those who don't show up run the risk of being chosen.
Re: DMD Compiler as a Library: A Call to Arms
Now on front page of HackerNews! https://news.ycombinator.com/news
Re: A Conversation with Martin Kinkelin on LDC
Martin is indeed a treasure!
Dlang mtg at Red Robin in Overlake 7pm tonight
be there or be square!
Re: Would this be a useful construct to add to D? auto for constructor call.
On 1/23/2024 8:01 AM, Steven Schveighoffer wrote: zero proposals that infer type from how they are used have been accepted by Walter, this one probably will be no different. Types are inferred in D from the bottom up. Mixing in special cases of it being top down leads to confusion over how the type is determined.
Re: Preparing for the New DIP Process
On 1/21/2024 3:51 AM, zjh wrote: When you need `friend`, You can put them all in one module. Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home. D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class. This encourages a different use of modules than C++ "toss code randomly into different source files."
Re: Preparing for the New DIP Process
On 1/21/2024 3:46 AM, Dom DiSc wrote: `class-private` is superfluous cruft. You can very easy live without it. And it has only no side effects, if it is implemented without `friend`s. But without this misfeature it is incomplete. Therefor it was decided not to implement it. It would be ok for me to add `class-private` as is, but only with the guarantee that `friend`s will never be added, no matter how much the people using it cry, because it is sometimes unusable without them. The irony is that the presence of class private in C++ wound up motivating the friends feature, which violates private left and right. D did it right with module level privacy, which is enforced. C++ private isn't private, const isn't constant, and one can throw from nothrow functions. D users do ask for non-constant const, impure pure, and GC allocating @nogc. You *can* do these things in D by using forcible casts in @system code. The salient difference between that and C++ is that the D compiler still assumes those invariants are in force, whereas C++ compilers cannot.
Re: Preparing for the New DIP Process
This is going to be a great initiative. Thanks, Mike!
Re: Upcoming talk at FOSDEM 2024 - The D Programming Language for Modern Open Source Development
On 1/14/2024 3:16 PM, Mike Shah wrote: My talk on how I'm using the D programming language and why I think it is an excellent language choice for open source projects will be featured at FOSDEM 2024 at the start of February 2024 in Brussels, Belgium. Ehhxcellent!
Re: Happy New Year!
On 1/5/2024 2:53 AM, Martin Tschierschke wrote: And BIG THANK YOU, to the whole community! Our pleasure!
Re: Beta 2.107.0
Nice work!
Happy New Year!
Along with my best wishes for a happy and prosperous 2024 to all the DLF community members, and their families and friends.
Re: Release D 2.106.1
Ehhxcellent!
DLang Club "Ferrari" at Regal Bella Bottega Theater Wed Jan 3 7:10 PM
What could possibly go better with #dlang than a Ferrari? Come enjoy the Ferrari movie with us. Bring a friend! https://www.showtimes.com/movie-theaters/regal-bella-bottega-stadium-11-8026/ 8890 NE 161st Ave, Redmond, WA 98052 844-462-7342 Send me an email to get on the Dlang Club mailing list. If you don't, too bad, so sad.
Re: Seattle D Meetup Mailing List - Ferrari Night
On 12/17/2023 2:53 AM, Adam Wilson wrote: You have my email already! Of course!
Seattle D Meetup Mailing List - Ferrari Night
If you want to be on it, email me your address! We hope to have some fun activities for D aficionados. For example, I am planning "Ferrari Night" towards the end of the month where we all meet at the theater to watch "Ferrari". https://www.imdb.com/title/tt3758542
Re: Seattle Area D-Meetup
On 12/12/2023 9:52 AM, Gregor Mückl wrote: Hi! I'm interested in joining this time. Looking forward to meeting you all! It was fun to meet you! Glad you could come.
Re: Seattle Area D-Meetup
6 of us attended, and we had a grand time! After Red Robin threw us out at 10PM because they were closing, we continued for another hour in the parking lot.
Re: ImportC has improved macro support
On 12/7/2023 9:17 PM, Ki Rill wrote:
This is amazing!
All in a day's work!
It should solve the disappearing of enum-like definitions in
code. I encountered this in Raylib. It has colors defined as macros:
```c
#define WHITE (Color){255, 255, 255, 255}
```
I preprocessed the file and all color definitions were gone. I had to redefine
them manually.
Give it a try, it should work now!
Re: ImportC has improved macro support
On 12/6/2023 12:43 PM, Dave P. wrote: Does this work for function-like macros? Not yet. It just lays the groundwork for that.
Re: ImportC has improved macro support
On 12/6/2023 11:59 AM, Walter Bright wrote:
Macros with the pattern:
#define BOO ( expression )
are now translated to:
auto BOO()() { return expression; }
and are available for importing!
The interesting thing here is `expression` does not need to be translated to D.
It's still a C expression, and has C semantics. D templates with C semantics
just falls out of the way ImportC was implemented.
ImportC has improved macro support
Macros with the pattern:
#define BOO ( expression )
are now translated to:
auto BOO()() { return expression; }
and are available for importing!
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/28/2023 1:54 PM, bachmeier wrote: I wonder if Walter has an opinion on this. In a .c file: It looks like the author is self-taught with little exposure to other programmers.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/26/2023 2:30 AM, John Colvin wrote: Good talk. Many very clever people would achieve more if they tried to understand why a v. experienced developer would care to spend so much time talking about what might appear to be such basic points. The key challenge: If this stuff was so obvious & everyone did it or it didn't matter so much that they didn't, why would Walter care about it so much? Like user interfaces in an airplane cockpit, it all looks obvious. But, as I was told by the lead engineer for the 757 cockpit, every aspect of it was paid for with somebody's blood.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/3/2023 8:10 AM, matheus wrote: I understand the advantages of the UFCS, I was just pointing out that the example given in that post are NOT equivalent, if it was deliberated or not I don't know, but I think it was just a small mistake, otherwise the author woundn't say they are equivalent. It was a mistake made by me.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/18/2023 11:51 AM, Max Samukha wrote: On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote: $0. true It's one reason why donations to the DLF go a long way. We try hard to squeeze the most out of every dollar.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/8/2023 6:21 AM, sighoya wrote: I have another thing to add. You argued about reasons not to use macros but these reasons don't apply to AST Macros, they won't allow constructing new languages like in Lisp or in Neat. Typed AST Macros would only accept parseable D source code with correct typing while untyped AST Macros would relax typing issues but syntax is still valid D. It's still inventing one's own undocumented, incomprehensible language. > Scala I've heard from an expert insider source that Scala macros destroyed the language. Macros are like selling your soul to the devil. At first it's a honeymoon, which may last for a decade or more, but eventually you discover you're in a trap you cannot escape. Seeing the life cycle of macros over and over is one advantage to me having been programming for well over 40 years.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/7/2023 5:37 AM, sighoya wrote: Thanks, I think we need more of this as D has become a large language already. There were some points I even never considered before. I'm glad it's a win for you! I disagree however in all binary types should be just boolean. I prefer machineState=State.On or State.Off than isMachineOn=true or false. Give it time. You'll come around! I've gone done many paths over the years on this stuff, to arrive at what I presented. I may evolve further in the future.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/5/2023 10:21 AM, angel wrote: I don't mind if it does not compile without the `ref`, but it should be on the table - WYSIWYG. It's a good point. Consider the refactoring angle. If I wished to switch from a struct to a class, and vice versa, and can just change the definition. If `ref` was needed everywhere, I'd have to refactor a lot of code. This is also why D uses `.` instead of `->`. Easier to refactor.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/5/2023 6:30 AM, claptrap wrote: While I agree with the overall gist I didn't find his examples very interesting or convincing. They were pretty much all made up to illustrate, outdated, or disingenuous (the first one with the intentionally obfuscated code). I know they look trivial, but I trivialized them to get them to fit on a slide. There are few more worthless slides than ones with 50 lines of code on them. Nobody can understand 50 lines of code in a minute, let alone hear the presenter talking about it. It would have been far better if he had actual real code examples he'd cleaned up. With many of them I included a link to a pull request that cleaned up a real example in DMD. (The real examples, of course, tend to be a bit more complicated.) I'm sorry you didn't find it worthwhile.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/4/2023 5:53 PM, claptrap wrote:
I have never once said he cant talk about whatever he wants to, I've explicitly
said the opposite. All I said is that by virtue of who he is has more
interesting things to talk about than whether "enum { yes, no }" is a good idea
or not.
When I stop seeing that kind of thing in the dlang code base ... :-)
Arguments about the things I talked about show up again and again in the n.g.
They are not commonly accepted.
Lastly, it seems obvious. But that's the point! It's very hard to write
self-evident code, and it looks trivial after the fact.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/4/2023 12:50 PM, claptrap wrote: Yes he can do what he likes, nobody has the right to demand anything from him. But his position and experience and knowledge is such that him doing a talk on coding guidelines is disappointing. Considering how few people follow the coding guidelines I presented, it's worthwhile. It isn't the usual guidelines I see, either.
Re: Blog post: How we are using D to develop Aspect from the ground up
On 10/23/2023 12:02 PM, Sönke Ludwig wrote: Link: https://aspect.bildhuus.com/blog/posts/how-we-are-using-d-from-the-ground-up https://x.com/WalterBright/status/1717077828255228223
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/3/2023 12:36 AM, Max Samukha wrote: 'No hire' for language designers who design sum types to be implicitly enumerated and convertible to integers and booleans? There's a reason my salary from the D Foundation is $0.
Re: From the D Blog: Crafting Self-Evident Code in D
HN front page, too! https://news.ycombinator.com/news
Re: D syntax highlighting in Nano
On 8/9/2023 7:25 PM, Doigt wrote: whoa that's pretty cool you could do it in D, I had to write my syntax file using regexes :-( I feel so sorry for you!
Re: D syntax highlighting in Nano
On 8/7/2023 5:43 PM, Doigt wrote: Would be nice to have feedback. I made a PR for the improved nano syntax project because I don't have a gitlab account to contribute directly to the nano project, but feel free to fork and do it yourself if you feel it's important/good enough. Here's the PR: https://github.com/galenguyer/nano-syntax-highlighting/pull/2 Nice! For fun, here's the one I wrote for microEmacs: https://github.com/DigitalMars/med/blob/master/src/med/syntaxd.d
Re: Forums are back up!
On 8/7/2023 10:35 PM, Vladimir Panteleev wrote: It would have been nice to be in the loop so I could have helped avoid this situation; oh well! Sorry about that. Will include you next time.
Re: Evolving the D Language
On 7/6/2023 8:14 PM, Richard (Rikki) Andrew Cattermole wrote: And for the record I still want hex strings to come back. They were incredibly useful with no good alternatives when we talk about large tables of data being described. For reference: https://github.com/dlang/dmd/pull/13773
Re: Evolving the D Language
On 7/7/2023 7:56 AM, Guillaume Piolat wrote: It just seems to me, instead of complaining when features become deprecated, people will complain when obsolete feature becomes deprecated and they see the message. The proposal here is that they see the message later. In the meantime, nothing will prevent people from using the obsolete feature all over. The problem has a lot to do with people wanting to use 3rd party libraries, and it being impractical to upgrade those libraries when the maintainer of those libraries is no longer active. If a user's project depends on several such libraries, it places an undue burden on the user.
Evolving the D Language
As time moves on, the D language has to evolve as well. What do we do with obsolete and/or problem-causing, legacy features? Our answer was deprecation. The deprecation starts out as just a message, which can be disabled, or can be set to be errors. The deprecations could last for many years, then become errors, but with a "-revert" switch if one still wanted to use them. I thought that was a straightforward approach, giving people many years to modernize their code. I was wrong. I heard you. We're going to have to change course. We also failed with the `alias this` for classes deprecation, in that we did not offer a reasonable replacment. We need a new approach to evolving the language (because evolve or die). I'm working on the following: 1. continue to evolve the language 2. not deprecate things unless we have to 3. keep legacy code running without complaint as long as we can 4. re-evaluate current deprecations with this in mind 5. resurrect selected legacy constructions that have been removed 6. better documentation for evolving legacy constructions To that end, we have a new switch: -wo Currently, the switch does nothing (!). But its intent is, when thrown, to give a warning about use of legacy constructions (adding -we will also make them errors). The idea is to simply not bother people building legacy projects with annoying messages, unless they are pro-actively asking for those messages. This way, people can modernize their code at their pace, not at our pace. But what about constructions that we have learned are unsafe and shouldn't be used in @safe code? Code that uses unsafe constructions is not necessarily buggy code. It may be perfectly correct, it's just that the compiler cannot *prove* it is correct. This means the compiler will continue to accept @safe code with unsafe legacy constructs. If you need the compiler to do the more thorough @safe checking, -wo will have to be used, and you can scrub out the old constructs as you see fit. Your thoughts and advice are appreciated. Feel free to add this thread your wish lists on legacy feature resurrection that should have priority. Or if you've got a better idea, let us know! And yes, `alias this` for classes is going back in.
Hotels at DConf
Hotels are running out of room, and prices are going up as a result. Book ASAP. #dconf
Re: On Mir parts migration to DRuntime
Thank you, this is great news! But the license is different from the license Phobos uses, and with the conditions it makes the most sense to add your libraries to the dub repository. That way it will be easy to conform to your requirements.
Re: LDC 1.32.2
On 5/12/2023 1:30 PM, kinke wrote: Thanks to all contributors & sponsors! Yes, indeed!
Re: A New Era for the D Community
This initiative has my full support.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times.
Re: Walter on Twitter
You make a good case. I'll think about it.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/26/2023 1:19 AM, Stefan Koch wrote: While it is true that it only implements a subset of the proposal. It does implemnent function overloading for non-templated functions the specific code for this is here: https://github.com/dlang/dmd/pull/14650/files#diff-fdd319cc59bac2d5ef6bc04f806fd564a3549e1cce44c7d01b4ec9e40792e3daR7172-R7190 Thanks for the correction!
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 4:12 PM, max haughton wrote: I have never been in favour of D having bitfields. This isn't worth breaking stuff for. D bitfields didn't break anything. Also, it exposed an overlooked bug in the ImportC bitfields.
Re: Walter on Twitter
On 4/18/2023 6:36 AM, Petar Kirov [ZombineDev] wrote: On Tuesday, 18 April 2023 at 03:02:16 UTC, Walter Bright wrote: On 4/15/2023 6:49 AM, Monkyyy wrote: By all means fund and promote *live coding* or teaching videos if you want to outreach, but shitposting on twitter wont do anything of value Mike has also suggested I do some live coding videos. That would be awesome! I'm sure many people would find it very interesting to see how you work - both your approach to solving problems and day-to-day techniques like your own Micro Emacs D editor. I'm just afraid it will consist mostly of me staring at the screen with a baffled look.
Re: Walter on Twitter
On 4/15/2023 4:12 AM, Hipreme wrote: Great! I'll try starting to do that also since we most of the time we're here posting only to existing D users, being in an unfiltered platform such as twitter could help too. Good! I've started doing that kind of work on instagram since images tells a lot there. Keep us posted on how it works.
Re: Walter on Twitter
On 4/15/2023 6:49 AM, Monkyyy wrote: By all means fund and promote *live coding* or teaching videos if you want to outreach, but shitposting on twitter wont do anything of value Mike has also suggested I do some live coding videos.
Re: Walter on Twitter
On 4/14/2023 5:54 PM, zjh wrote: Can you create a special post in the forum? This way, it is safer and more convenient. That is a good idea to do that as well. But I have no idea why would be safer? Anyhow, the idea with Twitter is outreach to a larger audience. Newspapers all do it, why shouldn't we? Some hashtags to follow: https://twitter.com/hashtag/dlang https://twitter.com/hashtag/ImportC
Walter on Twitter
I've had a twitter account for 15 years now (!) and haven't used it much for anything. But lately I've decided to use it to give regular updates on D things I've been working on. You can follow me on: https://twitter.com/WalterBright I encourage other D users on twitter to do the same!
Re: D Language Foundation March 2023 Monthly Meeting Summary
On 4/11/2023 7:35 PM, bachmeier wrote: Can't the changes to those files by stored in the compiler? Walter obviously can't change the raw header files, but he can make changes to the files before they're used by the compiler. If that's not possible, can't a modified set of header files be available for download, and if you want to use a system .h file, you have to use the modified version instead? It's a seductive idea, and I've considered that (and variations on it) many times. We have done this, after a fashion, in having our own versions of the .h files in the form of the D translations in core.stdc.* import files. The trouble is, there are endless C .h files out there, and they change essentially randomly. We've been tripped up with this by the windows .h files changing and breaking our translations of them in druntime. It's made worse by there being no way for us to realize those .h files have changed, while we merrily keep using the existing translations. Diemos has also had constant problems with changing .h files, which only gets discovered when a user runs into a problem. A huge point to ImportC is to become resistant to arbitrary changes by compiling whatever those .h files happen to be. Since we don't have an army of people willing to constantly create our own versions of the .h files, it's our only practical option. You can see some of the adaptations for specific .h wackiness in druntime's importc.h and _builtins.di files.
Re: Release D 2.103.0
On 4/3/2023 9:41 AM, Iain Buclaw wrote: Glad to announce D 2.103.0, ♥ to the 43 contributors. And a special thanks to you, Iain, for deftly managing the releases!
Re: LDC 1.32.0
Ehhxcellent!
Re: Dennis Korpel's DLang Contributor Tutorials
On 3/5/2023 5:19 AM, Mike Parker wrote: If you aren't subscribed to our YouTube channel and [missed the first announcement](https://forum.dlang.org/thread/ljyxxtlaooxzwymad...@forum.dlang.org), you might not know about Dennis Korpel's DLang Contributor Tutorials. I've just published Part 4, "Runnning the Test Suite". You can [watch that now](https://youtu.be/ETaPpydbFg8), but if you haven't seen the first three parts, I suggest you [watch the whole playlist first](https://www.youtube.com/playlist?list=PLIldXzSkPUXXSkM5NjBAGNIdkd4Q2Zf0R). We had planned to keep two a two-week publishing schedule, but Part 4 was unfortunately delayed. We should be able to get back on track now. So stay tuned for Part 5. Thank you, Dennis and Mike!
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/28/2023 5:04 AM, Johan wrote: Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code? No. We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors. It's been a while, but I think the only difference is if you're taking the address of a property. Without the @property, the address of the function will be taken. With @property, the address of the return value will be taken. This will affect inference, such as `auto x = ` That will likely lead to type mismatch errors further down the line, but I can't guarantee it. The best approach I can recommend is to remove the @propertys a handful at a time, checking them into git, and running your test suite to check for any failures. This will make `git bisect` invaluable in tracking down the cause of any errors that are missed by the test suite.
Re: LDC 1.31.0-beta1
On 1/27/2023 12:35 PM, kinke wrote: Glad to announce the first beta for LDC 1.31. Major changes: Nice work!
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/23/2023 11:21 PM, Siarhei Siamashka wrote: But the safety is not exactly great. It does (and always has) resolved the #1 memory safety problem - buffer overflows. If you use @safe, and the GC for allocations, it is just as memory safe as Python.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/11/2023 8:15 PM, Tejas wrote: Well, the companies don't get to single-handedly decide what features to add or deprecate, thanks to C spec being written by ISO, which is why they have developed their own PLs. Yes they can, as they add extensions to C all the time. But also, adding dynamic arrays to C won't make the currently existing C code safer, the one they care about, because no one's gonna send the money to update their C89/99/whatever code to C23/26. Even if they did, there's no guarantee others would as well. You can incrementally fix code, as I do with the dmd source code (originally in C) regularly.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/11/2023 3:26 AM, Paulo Pinto wrote: It is kind of "solved", by turning all computers into C machines, What an amazing amount of work just to avoid adding dynamic arrays to C.
Re: Safer Linux Kernel Modules Using the D Programming Language
By the way, back in the 80's, I wrote my own pointer checker for my own use developing C code. It was immensely useful in flushing bugs out of my code. There are vestiges of it still in the dmd source code. But it ran very slooowwly, and was not usable for shipped code. A lot of very capable engineers have working on this problem C has for many decades. If it was solvable, they would have solved it by now.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/10/2023 10:49 PM, Siarhei Siamashka wrote: It's impractical to have this in the ISO standard, but surely not impossible. Various C compilers from different vendors implement bounds checking. See: * https://bellard.org/tcc/tcc-doc.html#Bounds This works by constructing a data structure of all the allocated memory, and then comparing a pointer dereference to see if it's pointing to valid data. It sounds like what valgrind does. It's very slow, and wouldn't be used in a shipped executable, like you wouldn't ship valgrind. It's vulnerable to memory corruption when your app gets tested with inputs that were never tested when this checking was turned on. * https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html Adds a bunch of runtime checks you wouldn't want to ship an executable with them turned on. * https://clang.llvm.org/docs/AddressSanitizer.html Same problem. 2x slowdown, won't use it in shipped executable. * https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-native-run-time-checks?view=vs-2022 Not really clear what this does. So your statement that "C has no mechanism to prevent them" just ignores reality and the existing C compilers. If you are comparing the lowest common denominator ISO C spec with the vendor specific DigitalMars D implementation, then this is not a honest apples-to-apples comparison. They all seem to have the same problem - they are only useful when the program is under test. When the program is shipped, they're not there. The Linux kernel is using GNU C compiler and recently switched from `-std=gnu89` to `-std=gnu11`. Bounds checking in the Linux kernel is done by https://docs.kernel.org/dev-tools/kfence.html or Being sampling based, this is not good enough. https://docs.kernel.org/dev-tools/kasan.html Another test-only tool. Please don't misunderstand me, these tools are good. But they have really nothing to do with the C language specification (which is completely unhelpful in resolving this issue), have too high overhead to be useful in a shipped product, and have not stopped C from having buffer overflows being the #1 bug in shipped software. I stand by the idea that C's semantics make it impossible. These tools are all things layered on top of C, and they certainly help, and I would use them if I was developing in C, but they simply do not solve the problem.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/8/2023 8:31 PM, Siarhei Siamashka wrote: On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote: Buffer overflows are trivial to have in C, and C has no mechanism to prevent them. ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the practical mechanisms to prevent buffer overflows. And yet C buffer overflows are consistently the #1 problem in production C code. Valgrind, etc., only detect overflow if there's a test case that causes overflow. That's why it's not as good as static checks. Clang Static analyzer can only detect a small subset of buffer overflows. Yes, they are not baked into the ISO language standard. They can't be because the C semantics make it impossible. But D has no ISO language standard at all. Neither does Rust. D can do everything C can. And more. Valgrind works with D code, too.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/8/2023 10:34 PM, Paulo Pinto wrote: The best part of memory safe systems programming languages is that many of those tools don't even have to exist, they are part of language semantics! Exactly! I once annoyed the Coverity folks by telling them that my goal with D was to make Coverity irrelevant.
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/7/2023 2:25 PM, areYouSureAboutThat wrote: In fact, C can be used in a perfectly memory safe manner. Yes, as long as you don't make any mistakes. A table saw won't cut your fingers off if you never make a mistake, too. The problem is that too few programmers know how to do that, and even very experienced C programmers can get it wrong sometimes. Both tools and compilers have come along way over the last decade, and it's getting increasingly 'harder' to write memory unsafe C, but in the end, in C, its the programmer that has the control. Buffer overflows are trivial to have in C, and C has no mechanism to prevent them. Buffer overflows are consistently the #1 security problem with production C code. But C will always be the language that gives the programmer the flexibilty and control needed, when all the other languages will not. There's nothing you can do in C that you cannot express in D, with the same code being generated. Even bitfields! To be 'C like', the language needs to provide the same flexibility and control as C, and map to the hardware and its instructions set as well as C. In other words, it's going to end up being C anyway. Or DasBetterC!
Re: Breaking news: std.uni changes!
A big thank you!
Re: text based file formats
On 12/20/2022 1:51 PM, Adrian Matoga wrote: I frequently find it useful for a text data file parser to call a diagnostic callback instead of assuming some default behavior (whether that's forgiving, printing warnings, throwing or something else). With template callback parameters the parser can throw if the user wants it or stay pure nothrow if no action is required. Yes, sometimes I think this might be the right answer.
Re: text based file formats
On 12/21/2022 6:27 AM, Adam D Ruppe wrote: On Tuesday, 20 December 2022 at 00:16:57 UTC, Walter Bright wrote: LOL, learn something every day! I've even written my own, but it isn't very good. Yeah, I wrote a csv module too back in... I think 2010, before Phobos had one. It is about 90 lines, still works. Nothing special but I actually kinda like it. https://github.com/adamdruppe/arsd/blob/master/csv.d What this all means is Phobos could use a better one!
Re: text based file formats
On 12/20/2022 8:19 PM, 9il wrote: It has already been replaced with [mir.csv](https://github.com/libmir/mir-ion/blob/master/source/mir/csv.d). Mir is faster, SIMD accelerated, and supports numbers and timestamp recognition. Propose this for Phobos?
Re: text based file formats
On 12/20/2022 11:46 AM, John Colvin wrote: We use this at work with some light tweaks, it’s done a lot work Sweet!
Re: text based file formats
On 12/19/2022 4:35 AM, Adam D Ruppe wrote: On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright wrote: Curious why CSV isn't in the list. Maybe std.csv is already good enough? LOL, learn something every day! I've even written my own, but it isn't very good.
Re: DConf Online '22 Day Two Livestream
On 12/18/2022 5:08 AM, Mike Parker wrote: We're coming up on the start of the Day Two livestream. I'll get it started at 13:45 UTC. I'll jump in around 13:50, and Walter will join me at 13:55 just before his talk starts. See you there! https://youtu.be/VCgdajZconA Another marvelous DConf day! Afterwards, I hung out a bit at Beerconf and we had a great and productive discussion. A shoutout our glorious contributors: Larry Hemsley Mike Shah Steven Schveighoffer Brian Callahan (presentation *and* workshop!) And, of course, none of this would have worked without our indefatigable Mike Parker, who wore many hats: DJ, MC, Editor, Manager, Host, Roadie, Organization Man, Audio/Video Engineer, Youtube Coordinator, Cruise Director, and Man Behind The Curtain.
Re: text based file formats
On 12/18/2022 7:56 AM, Robert Schadek wrote: So stop talking, and start creating PR's. Yup! Curious why CSV isn't in the list. I encounter that a lot at tax time. https://en.wikipedia.org/wiki/Comma-separated_values Maybe just ask OpenAI?
Re: DConf Online '22 Day One Livestream
On 12/17/2022 5:12 AM, Mike Parker wrote: The DConf Online Day One Q & A Livestream kicks off in less than an hour. See you there! Many thanks to today's speakers: Átila Neves Max Haughton Robert Schadek Dennis Korpel Adam D. Ruppe who obviously spent a lot of time and effort preparing their segments for our enjoyment! Extra special thanks to Mike Parker for organizing, editing, and MC-ing a great show! Looking forward to tomorrow's followup: https://dconf.org/2022/online/index.html#schedule Since I'm going first at the crack of doom, er, dawn, be sure to come well armed with a large coffee (or two).
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On 11/2/2022 4:19 AM, Steven Schveighoffer wrote: https://briancallahan.net/blog/20220704.html That's now in the "new" section of HackerNews! https://news.ycombinator.com/newest
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On 11/2/2022 4:19 AM, Steven Schveighoffer wrote: On one of the only articles using ImportC (which otherwise shines a positive light on the feature), this specific issue is the only one that comes up as a blocker: The easiest option would be to simply ignore "const" when it is "const pointer to mutable".
Re: Ali introduced D at Northeastern University
Just posted it in the "New" section of HackerNews
Re: Meanwhile on the audio front
On 9/22/2022 6:10 AM, Guillaume Piolat wrote: September was a great month for the D sub-community around #Dplug & #audio. Very nice work!
Re: DConf '22 Slide Links and Update on Videos
Thank you, Mike!
Re: Giving up
On 8/6/2022 1:29 PM, Timon Gehr wrote: Seems you should just use a long double/real literal? real x = 0x1p-16383L; // (works) Looks like that settles it. (Why didn't I notice that? Sheesh!)
Re: Giving up
On 8/6/2022 4:08 AM, Max Samukha wrote: UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.) We could, and enter the inevitable bug report from the baffled user who can't figure out why UFCS stopped working for his algorithm-generated function names. At some point, we just have to accept there's going to be a compromise.
Re: Giving up
On 8/6/2022 2:02 AM, Tim wrote:
It could silently break code if the right function is defined. The following
example is valid in C and D (except import/include), but prints a different value:
```D
// #include
import core.stdc.stdio;
int E2(int i)
{
return i;
}
int main()
{
float f = 123.E2;
printf("%f\n", f);
return 0;
}
Congrats, you got me there!
Re: Giving up
On 8/5/2022 9:43 AM, Max Samukha wrote: Both "123." and "123.E123" is valid C. For some reason, D only copied the former. It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better). So, does it work with ImportC? test2.c: float z = 85886696878585969769557975866955695.E0; long double x = 0x1p-16383; dmd -c test2.c test2.c(3): Error: number `0x1p-16383` is not representable So the first one does compile as expected with ImportC. Let's try gcc and clang: gcc -c test2.c test2.c:3:1: warning: floating constant truncated to zero [-Woverflow] long double x = 0x1p-16383; ^ clang -c test.c test2.c:3:17: warning: magnitude of floating-point constant too small for type 'double'; minimum is 4.9406564584124654E-324 [-Wliteral-range] long double x = 0x1p-16383; nd, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero? We've got the right choice here, but it's definitely a judgement call.
Re: LDC 1.30.0
On 7/20/2022 11:43 AM, kinke wrote: Glad to announce LDC 1.30.0. Yay!
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On 7/11/2022 2:18 PM, bachmeier wrote: One reason is that the editing can be done automatically by services like Descript. I don't know if Mike does it manually. Doing it automatically means then you've got to spend time comparing the two to ensure it cut in the right places :-(
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On 7/10/2022 8:26 PM, Mike Parker wrote: On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: Have you considered uploading the audio to Spotify or somewhere as a podcast? No idea what that would involve, but for a lot of us there are more opportunities to listen to a podcast rather than watch a YT video. That hadn't crossed my mind. I'll look into it. A podcast channel for D stuff sounds like a great idea!
Re: The D Programming Language Vision Document
Mike has our full support in his moderation policy and authority.
Adding Modules to C on Hacker news
#28 on the front page https://news.ycombinator.com/news
Re: Adding Modules to C in 10 Lines of Code
On 6/5/2022 10:49 PM, Paulo Pinto wrote: On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote: That are *C* compilers doing imports for *C* code? https://clang.llvm.org/docs/Modules.html And I am out of this thread. I had thought that was just for ObjectiveC. It seems it does work for C, though the user has to create "module map" files: "To actually see any benefits from modules, one first has to introduce module maps for the underlying C standard library and the libraries and headers on which it depends. The section Modularizing a Platform describes the steps one must take to write these module maps."
Re: Adding Modules to C in 10 Lines of Code
On 6/4/2022 10:54 PM, Paulo Pinto wrote: That paper had a real implementation to follow along, I didn't see it. while Lucid and IBM products were real things one could buy. That are *C* compilers doing imports for *C* code? What C compilers have imports: gcc - nope clang - nope VC - nope Digital Mars C - nope C Standard - nope ImportC - yes!
Re: Adding Modules to C in 10 Lines of Code
On 6/5/2022 7:26 AM, mee6 wrote: On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote: On 6/4/2022 5:29 AM, Paulo Pinto wrote: I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual. Writing a paper is not doing it first. Why do you care so much about being "first"? Would you not have implemented and made a presentation about it if you didn't think it was the first implementation? Because it's fun to be first!
Re: Adding Modules to C in 10 Lines of Code
On 6/4/2022 5:29 AM, Paulo Pinto wrote: I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual. Writing a paper is not doing it first.
