Re: Sovereign Tech Fund: call for proposals

2024-06-18 Thread Dom DiSc via Digitalmars-d-announce

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

2024-05-25 Thread Dom DiSc via Digitalmars-d-announce

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

2024-01-23 Thread Dom DiSc via Digitalmars-d-announce

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

2024-01-21 Thread Dom DiSc via Digitalmars-d-announce

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

2024-01-21 Thread Dom DiSc via Digitalmars-d-announce
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

2024-01-21 Thread Dom DiSc via Digitalmars-d-announce

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

2023-10-05 Thread Dom DiSc via Digitalmars-d-announce

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

2023-10-03 Thread Dom DiSc via Digitalmars-d-announce

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

2023-08-14 Thread Dom DiSc via Digitalmars-d-announce

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

2023-02-27 Thread Dom Disc via Digitalmars-d-announce

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

2023-02-25 Thread Dom Disc via Digitalmars-d-announce

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

2023-01-26 Thread Dom Disc via Digitalmars-d-announce

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!

2022-12-25 Thread Dom Disc via Digitalmars-d-announce
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

2022-06-23 Thread Dom Disc via Digitalmars-d-announce
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

2022-06-06 Thread Dom Disc via Digitalmars-d-announce

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).