SilentLambda

According to ChatGPT, the CobaltC language specification does now (since the spec was recently updated with an errata) provide sufficient syntactic, structural, and semantic boundaries to begin high-level compiler implementation planning, despite intentionally leaving lower-level mechanical decisions to the developer.

Yes, but remember is the last appendix to a book, and book provides the context for this appendix. So yes, in that sense, it's just another one attempting to address the memory-safety issues of C. At least this one uses C like syntax and doesn't require C programmers to learn some alien syntax. Of course, this is just a spec, Rust is well and truly live in the environment. The book is more interesting than the spec.

alert, inform, notify, announce ..... that's what HN does.

How about refocusing your attention on the actual matter at hand.

That is, Linus calling out Kees for being actively malicous.

Personally, I would have contacted Konstantin privately to lock (at least temporarily) Kees account. Then I would have sought an explanation from Kees (on the mailing list), and waited for his response. And I would have done this before calling him out as being guilty of active maliciousness.

Of course Linus love drama (especially drama that he creates.).

I think the HN title was completely appropriate.

Linus was not jusy yelling - (i.e.): "You seem to have actively maliciously modified your tree completely." - Linus Torvalds.

Linus didn't even use the word 'potentially' - yet the HN title did.

So get off the back of the person who created the HN alert!

openD (a fork of the D programming language) makes class private members inside a module a reality for programmers. In the meantime, the D programming lanaguage forum bans any further discussion of private(this).

Members of the D programming language spend 14 weeks searching for the elusive 'self'. Did they all find it though? And what about the 'non-self'? Did they go looking for that as well?

This D programming blog argues that C++ friend breaks encapsulation. I reject that argument, and say that C++ friend puts a door in the wall, and a guard at that door, and therefore encpasulation both remains, but is also extended (in the same way entangled particles are both encapsulated in themselves, but also in their encapsulated partner particle(s).

The article also argues that D's approach to allowing all code within a D module to be within the perimeter of any class type within that module, at all times, enhances encapsulation. I propose, that such an approach can only break encapsulation of a class type, and that it cannot possibly enhance it.

..and in the context of a module.. not even used as a type at all.

Would have been much better in my opinion, if D had maintained a C like struct (not a C++ like struct), and a C++ like class. That would have solved the problem you identified, while still allowing for the class to be what it was designed to be. The mistake C++ made was the mistake you identified. But the solution you provided in D is its own mistake.

Yes, we can agree that D is not like C++ - not at all.

The reason C++ programmers are usually disappointed, is because D gets marketed as such (it's the bait you need to get them to look at D afterall).

In fact, even on the basic class type, C++ and D are really miles apart. Make no mistake about this - they are miles apart, even on this one construct (the same contruct for there being a C++ in the first place).

It is clear when you use D, that it wasn't designed to be like C++.

D does have a subset that is C like, and that's primarly because it is, in essence, C.

So D is D.

D is not at all like C++.

A subset of D is like C (cause it is - more or less - C).

D is not at all like C++.

D is D.

You only need to compare how C++ and D treat a class type, and you know straight away they are miles apart (I prefer C++ in this regard).

D has a subset, and that subset is more like C - pretty much cause that subset is C. That can be interesting to use, since it's like C with modules.

But don't be fooled. D is not like C++.

I wish people would stop saying as such, cause it's not at all true.

.. you forgot to mention also, that (in the context of a D module) D stops treating a user-defined class-type as real type. Additionally, a D class is a reference type. Whereas in C++, a class type is a real type (treated as any built-in type), and is a value type (by default).

Nor does D have a concept of C++ friend.

So even when it comes to classes, C++ and D are miles apart.

"That said, D definitely has some advantages over C++, like more powerful metaprogramming, no need for headers, no uninitialized values and more. But unfortunately, these upsides are outweighed by the downsides."

Yes, after working with D for far too long, I have decided to delete it off my computer and I'm going back to C++, where a class is still a first-class 'type', and a 'value' type at that (at least by default).

In D, a class is a reference type only and worse, the D language has no means of declaring, let alone enforcing at compile time, a perimeter around such a type, within the so called 'D module'. The entire D module is within the perimeter of your class type, at all times!