On Saturday, 22 May 2021 at 11:27:10 UTC, Ola Fosheim Grøstad wrote:

sigh

How ironic that the larger organizations are more nimble about these things than we, a vastly smaller community, are(or maybe that's why?)

I can't help but feel it might be best if I just left for C++20. Experimental stuff for C++23 is available anyways, can't be any worse than the bugs in the D compilers. If I want the flexibility of Python, I can learn how to embed boost.python properly.

And (if) when D's ambitions of Dpp and ImportC materialize, I will just automatically generate headers/modules for D. That's the intention, right?

... I think I've lurked in too many negative posts about D. Might be good to stay away from the general posts for a while. See you guys next month or later.

On Saturday, 22 May 2021 at 12:47:17 UTC, Tejas wrote:

C++ has had concurrency workgroups for a long time? And key Swift people have been involved with clang/LLVM? So it is not like this is happening fast, but they have prepared for it for a longer time perhaps?

I think only MS has C++20 implemented, clang has bits and pieces of it. I guess it will take one year for clang to have the full C++20 production ready.

But things are happening in the concurrency domain, for sure.

On Saturday, 22 May 2021 at 12:47:17 UTC, Tejas wrote:

Can't speak for you, but this is a no-option for me. C++ has a massive complexity bolted on it, you have an abundance of ugly code which won't be upgraded and will even grow as of today.
Still improved support for templates in C++ aren't enough to replace C macros, so you have to deal with them anyway.
The syntax still feels hard to read these days, I don't know.
And then developing without a GC and dealing with many memory containers which aren't that safely convertible to each other, no, thanks.

On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

+1

I think D will succeed if we just manage to focus

On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

I guess you are talking about libraries, sure most of the larger frameworks were designed many years ago and have outdated APIs. Also, many C++ programmers are set in their ways and continue to write code in their own set ways. More social than language...

D is becoming quite complex too though, it could be made simpler. D allows more compact syntax, but not sure what the effect of that is when you get large code bases.

As was pointed out, STL can be verbose, but the last versions have improved on that by language and library changes, so I am starting to find it bearable.

I don't use macros in C++... Not sure what you meant there?

Not sure what you mean by memory containers?

What makes C++ challenging is that libraries tend to focus on performance and detailed control, so that can often make them harder to set up and use than in other languages where speed is less in focus.

On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

This is point I have also thought about. If you only have one pointer type GC or not, then the algorithms of the data structures will work with any type of memory. Also there is no need for code duplication to work with different types of memory management containers.

Is is enough not to justify fat pointers? I personally don't think so. The generic programming of D is so good that you can create algorithms that will work with any MM container that you throw at it (with code duplication of course).

Not dealing with several MM containers like C++ (unique_ptr, shared_ptr, atomic_shared_ptr) and Rust is kinda nice, but only one like Nim with the "ref" keyword is acceptable I think.

On Saturday, 22 May 2021 at 16:12:12 UTC, IGotD- wrote:

Ok, so mean smart pointers. Never had a single issue with this. They are owning pointers, usually encapsulated as private class members. You typically don't pass them around much, and they are usually unique_ptrs unless the design is a mess. What you pass around are mostly views or borrowed pointers?

On Saturday, 22 May 2021 at 16:21:06 UTC, Ola Fosheim Grostad wrote:

It's not just that, every large framework tends to have their own pointers with their own memory reclaim rules, like QPointers in Qt, mixing them, and you slip into an unpredictable state.

On Saturday, 22 May 2021 at 16:53:49 UTC, sighoya wrote:

Yes, and their own strings etc, but they are usually out if date in their API design or just making up their own style... C++ is just not a good eco system for high level programming. For that purpose D with GC is obviously more accessible. C++ is good for low level programming, but one needs a well thought out model before coding. It is not a good language for prototyping and playing with ideas.

On Saturday, 22 May 2021 at 11:27:10 UTC, Ola Fosheim Grøstad wrote:

I came over this endless document outlining future Swift C++ interop today:

https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md

They have some limited capabilities already (although Objective-C++ is probably still better). Seems like Apple are putting a massive effort into C++ interop for Swift now, didn't really expect that.