On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
> On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
>> > THINGS TO DROP
>> --------------
>> * C++ interoperabiliy
>> Walter's right:  memory safety is going to kill C and C++ will go with it.  Don't waste time on this; it's not going to matter in 10 or 20 years.
> Thank you for making a list to give people an idea of what D3 could be, but I definitely don't support less interoperability with C++. I want D3 to have a better argument to transition from C++ than D2 has.  With all the C++ API's out there, making D incompatible would be a ginormous deal-breaker for a ridiculous number of projects.  D3 should seek to be worth the transition from C++.

Seems like there is a split right down the middle. The problem is of course that going down the middle is neither satisfactory nor innovative.

I agree with you, but I think the C++ compatibility is a lost game and increasingly so without aligning the core semantics. C++ is changing too...

Removing all C++ compatibility is a death sentence for D.  This may not be apparent to some people that already program in D, but it is downright critical to potential D users.  Zero C++ compatibility means that D can no longer interface with C++ libraries such as Qt, putting a severe limitation on it's uses.

At the very least, dropping C++ compatibility is not for D3.  If ever, it should happen when D is already as popular as C++.  I brought up this whole D3 idea because I feel like D just needs one more wave of breaking changes to the language and library to be brought to perfection.  There are many C++ programmers out there who looked into/tried D and felt like it was almost good enough.  I think it will just take one major breaking version to make them jump, but not if it's totally incompatible with C++.

D3 should make the changes that can be agreed between proud D users and C++ users who have hopes for D.

On Saturday, 17 June 2017 at 06:23:08 UTC, Suliman wrote:
> On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
>> On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
>>> > THINGS TO DROP
>>> --------------
>>> * C++ interoperabiliy
>>> Walter's right:  memory safety is going to kill C and C++ will go with it.  Don't waste time on this; it's not going to matter in 10 or 20 years.
> Totally agree! C++ now in 90% of cases is legacy projects. At current time is more important to out of the box interoperability with Rust or Julia. Time show that C++ do not want to migrate to D. Only few people come from C++ world, because all of them waiting of new C++ standard c++x2035 (or whatever)
Please don't quote me just to say "Totally agree!" to someone that I quoted and disagree with.

A prediction that C++ is going to be dead in 10 years is not good enough.  C++ is very active, not just legacy like you say.  As I said, D should not drop compatibility until it's ALREADY clear that it's getting surpassed by D.
I support interoperability with Rust if it's doable.  I barely know about Julia.

Like I said, there are actually many C++ programmers out there who feel like D2 has promise, but not quite there.  THIS is why I brought up this D3 idea.  I really do think that D3 could bring quite some excitement to the programming community if it's coming along well.  After a few of the more open-minded C++ programmers adopt D, it will trickle up to more and more.

Why for example not Rust (i am not its fan). I do not see any real perspective in C++. What to do in next 5 years if C++ will start loosing it's popularity? Implement D4?

Plus any backwards compatibility make implementation new ideas in language very hard.

On Sunday, 18 June 2017 at 07:14:24 UTC, Suliman wrote:
> Why for example not Rust (i am not its fan). I do not see any real perspective in C++. What to do in next 5 years if C++ will start loosing it's popularity? Implement D4?
>
> Plus any backwards compatibility make implementation new ideas in language very hard.

Both C/C++ are loosing popularity relatively speaking, but this is not because of the languages themselves. It is because more and more applications can be written either fully or in part in higher level languages.

So C++ is taking over parts of the former C domain, and other high level languages are taking over some parts of the C++ application development domain.

But C++ will still be big in 10 years.

> But C++ will still be big in 10 years.
Ok, let's assume it will be poplar in 10 years. But it's very short time. D exists almost 17 years.

And not every people need to interfacing with C/C++. For me it's more important to have static-typing and compilable alternative to Python. And a lot of people whom I know want same.

On Sunday, 18 June 2017 at 12:05:37 UTC, Suliman wrote:
> And not every people need to interfacing with C/C++. For me it's more important to have static-typing and compilable alternative to Python. And a lot of people whom I know want same.

I see this a lot, but then you have to ask yourself how many languages are trying to enter the same domain (faster Python).

In the end a language has to be the best for some particular domain to gain traction.

> Here are some ways that D3 can be an improvement of D2:
> -Final by default
> -A standard library that is effective with or without garbage collection

100% OK about the optional garbage collector, but I have to totally disagree with you on the "final by default" approach.

The current design keeps the code open to extension, in a perfectly complementary way to UFCS.

They are both incredibly useful, and are part of what makes D2 perfectly work as a strongly-typed JavaScript-like scripting language.

(I just had another proof of that this morning, see my recent post.)

And dropping C++ compatibility is a complete non-sense IMHO.

If you want more people using D, its interoperability with C and C++ should instead be improved, so that D applications can quickly and easily use any C/C++ 3D/2D/VR/audio multimedia libraries for instance...

On Wednesday, 14 June 2017 at 19:12:36 UTC, Jacob Carlborg wrote:
> You only need one, AST macros ;)

Not going to happen anytime soon, as we do not have much interest in DSL abuse.

On Thursday, 15 June 2017 at 18:26:57 UTC, Jesse Phillips wrote:
> In essence he is saying we should have immutable code releases. For example he would say that we should add a new namespace and not get rid of the original (std2.io, std2.xml, std2.json) now you can get your improvements out and not break anyone's code, for example he would say old modules would be deprecated but never removed.

Not much different from moving old code to Undead, requires very little work.
On a plus side you have to decide whether to upgrade your code or stick with the existing modules.

On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
> * Drop the GC or at a minimum make it opt-in.  Add a borrow checker, automatic reference counting, or some other GC alternative that doesn't require a separate thread.

AIUI D's GC doesn't use a separate thread:
https://dlang.org/spec/garbage.html#how_gc_works

"1. Stopping all other threads than the thread currently trying to allocate GC memory.
2. ‘Hijacking’ the current thread for GC work."

An earlier bullet point is confusing:
"Normally, all threads other than the collector thread must be halted while the collection is in progress."

Probably 'other than the collector thread' should be removed - 'collector thread' implies asynchronous collections.