Re: Sovereign Tech Fund: call for proposals
On Monday, 17 June 2024 at 19:44:15 UTC, angel wrote: "Slang" is actually a great name for a programming language. In german we can have a D-alekt of D :-)
Re: The D Programming Language and Its Role in Cybersecurity
On Saturday, 25 May 2024 at 07:58:35 UTC, aberba wrote: On Friday, 24 May 2024 at 19:54:16 UTC, Steven Schveighoffer wrote: On Monday, 20 May 2024 at 21:21:24 UTC, aberba wrote: Found this article by Raymond Andrè Hagen: https://www.linkedin.com/pulse/d-programming-language-its-role-cybersecurity-raymond-andr%C3%A8-hagen-nfvgf/ My goodness this is a terrible article. Almost no substance. Is this AI generated? -Steve Lol, the author looks like a seasoned security professional. Not for long if he continues to produce such garbage. The article contains almost no arguments, only a few claims without deeper reasoning, but those are repeated in each chapter with almost the same words. I assume even an AI can do better.
Re: Preparing for the New DIP Process
On Tuesday, 23 January 2024 at 07:29:33 UTC, Danilo wrote: The people who still put 50,000 LOC into a single file will not be happy with this. ;) Fair enough. I'm also not happy with their code.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 11:51:59 UTC, zjh wrote: When you need `friend`, You can put them all in one module. Jup. But putting things in one module won't do anymore if you use class-private. That's why people using it will soon realize they need friends. But friends are a security hole, rendering private completely useless at all. So adding class-private without friends is an incomplete feature, that will make nobody happy. But class-private with friends is a misfeature. Ergo: do not add class-private at all! All that's possible with class-private is also possible with module-private. But module-private don't has the friends-issue. Everything is good - you only need to realize that.
Re: Preparing for the New DIP Process
If you have difficulties to see the logic of module-private, think of a module as a flat: If you don't want someone to mess with your private stuff, don't live with him in the same flat! Be ensured, locks on every cupboard won't do. You cannot prevent someone within the same flat from messing with your private stuff. Most people realize that at some point in their life, so only few live together in the same flat. I hope you will also realize at some point in your life, that two classes should not live in the same module - except they are close friends.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:52:59 UTC, zjh wrote: On Sunday, 21 January 2024 at 07:51:00 UTC, zjh wrote: You don't know the `pain `of not having a certain feature, And this feature has already been `implemented`, even without `any side effects`! `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.
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote:
[...] he is has more interesting things to talk about than
whether "enum { yes, no }" is a good idea or not.
His point here was not that having an enum with values for yes
and no is a bad idea. The bad idea is assigning yes the value 0.
That's a much more subtle point, as here nowhere 0 is written.
That's what make this kind of mistakes so easy and I think it's
well worth to explain it to less experienced programmers.
It's not easy to make simple looking code. That has nothing to do
with (coding-)style, it is all about not defining things a
different way than it is usually done, so nobody mix it up.
Sometimes it's very hard to find the correct order of things -
often even experiments are necessary to determine what "usually"
means.
What he says is: Invest your time to find out what "usually"
means, and that is not trivial, even if it sounds like it is. It
requires a lot of experience to come to this conclusion.
Investing time to make things look easy and obvious is well worth
it, despite you're likely not payed (or in your case: honored)
for it.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 10:39:19 UTC, matheus wrote: I the first example "e" is receiving two arguments. While in the latter "d" is being receiving whatever "c" returns and "3". That's the point. In UFCS it is immediately obvious which function receives the 3, while with all the parenthesis it takes some time and concentration to find out, and getting it wrong is quiet easy.
Re: D Language Foundation July 2023 Monthly Meeting Summary
On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote: Maybe if the compiler detects that deprecated features are being used it could add a line to the output... "To check for usage of deprecated features use the '-wo' switch" A simple 1 line "friendly reminder" instead of pages of warnings, surely people could live with that? Jup, that's a very good idea.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance.
Re: Blog post on figuring out attribute inference failure
On Saturday, 25 February 2023 at 11:23:56 UTC, Dennis wrote: I'm working on it! https://github.com/dlang/dmd/pull/14911 Hurray!
Re: Qonquest 2 - A simple strategy game written in D
On Thursday, 26 January 2023 at 00:49:03 UTC, Adam D Ruppe wrote: It is my fault for resizing, i used width,height instead of width_,height_ so it used the pre-scaled things. [...] Or I'll see what I can do to clean up my branch and cherry pick this fix later in the week... There is nothing better to test a library than an application that's using it.
Re: Breaking news: std.uni changes!
On Saturday, 24 December 2022 at 21:26:40 UTC, Richard (Rikki) Andrew Cattermole wrote: - Unicode tables have been updated to 15 from 6.2 (and with that the generator is now in Phobos!). Hurray! Whatever problems this may cause, its problems in very very outdated code that would already need an overhaul, so what. But it's super to have finally tables that are (at least now) up to date!
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 21:58:07 UTC, Ola Fosheim Grøstad wrote: Some C programmers reuse variables extensively, those programmers will be confused or annoyed. And rightly so. Misra says since 30 years or longer: don't reuse variables if possible (and it should almost always be possible). If there exists now another way to shoot in your foot with this bad habit, so what?
Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote: cannot have encapsulation unless it is put into a super type (the module), all by its self (with no friends). It can have friends - they just need to be in the same file (module). And a class without its friend is really only half a type - that's why it is better to think of the module as the new type - which contains both the interface and all interna (friends and sub-classes and @system parts that should not be visible from the outside). That's what a file is for in general: to collect things that belong together and should be seen as a single object. It makes no sense to put other unrelated classes or functions into the same file. Especially not in a large project (which is the only case where encapsulation makes sense at all).
