Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated.

A lot of people need more powerful static-typing alternative to Python/C# for common tasks that allow to build stand-alone executable files.

I think it's bad idea to mix to paradigms. People who do not need GC at all already use Rust.

On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
> Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated.
>
> A lot of people need more powerful static-typing alternative to Python/C# for common tasks that allow to build stand-alone executable files.
>
> I think it's bad idea to mix to paradigms. People who do not need GC at all already use Rust.

Actually, D already supports GC-Free / manual memory management.

https://dlang.org/phobos/std_experimental_allocator.html
+
@nogc
= manual memory management

The issue is that the std library is still full of GC parts and so is third party software. But you can simply turn functions and classes that do not use the library / 3th party software into pure nogc parts. Think of it more as a hybridize system.

I think there is somebody here who was writing a non-gc library for D.

On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:
> I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along.
> Of course discussing which modules should be obsoleted is a tricky question.
>
> std.signals
> std.xml
> std.outbuffer
> std.socket
> std.json // maybe ;)
>
> I do not at all agree that a big language change is needed.
> We just changed the lookup rules with http://dlang.org/changelog/2.071.0.html and managed to make this a transition instead of a break.
> Also without a proposed feature list this discussion is somewhat lame.

Let's do this!

https://github.com/dlang/phobos/pull/5488

On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
> Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated.

We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII).

Memory management is only the tip of the iceberg of resource management ; it's the easy problem, where an automated process can to tell which resources aren't needed any more.

However, an instance of a class can hold a lot more than flat memory blocks: threads, file handles, on-disk files, system-wide events, sockets, mutexes, etc.

Freeing the memory of my "TcpServer" instance is mostly useless if I can't reinstanciate a new one because the TCP port is kept open by the freed instance (whose destructor won't be run by the GC).

On Thursday, 15 June 2017 at 17:06:31 UTC, Sebastien Alaiwan wrote:
> On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
>> Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated.
>
> We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII).

Not sure what exactly you are expecting, tbh. If you expect classes to be changed to behave like structs with regards to finalization: That can't happen, because they are reference types, not value types:
The lifetime of value type objects is statically known to end at their enclosing scope (unless they are moved), in contrast to reference types.

>
> Memory management is only the tip of the iceberg of resource management ;it's the easy problem, where an automated process can to tell which resources aren't needed any more.
>
> However, an instance of a class can hold a lot more than flat memory blocks: threads, file handles, on-disk files, system-wide events, sockets, mutexes, etc.

All of which you can easily take care of in the class' destructor and then .destroy such objects when needed.

>
> Freeing the memory of my "TcpServer" instance is mostly useless if I can't reinstanciate a new one because the TCP port is kept open by the freed instance (whose destructor won't be run by the GC).

*might not be run by the GC when you want it to.

Why are you even talking about the GC when your problem seems to require deterministic lifetime management. That's not what a GC does, and thus it's the wrong tool for the job.
The right tool here would be one of
- std.experimental.allocator.{make,dispose} (statically known lifetime)
- {std.typecons / automem}.RefCounted (dynamic lifetime)

On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:
> On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
>
> I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along.
> Of course discussing which modules should be obsoleted is a tricky question.

I just got done with watching this great presentation by Rich Hickey[1].
It's about change, how semantic versioning is broken, and why packages are wrong when it comes to dependencies.

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.

I don't agree 100% with him but he does make good points. Really what I'm hearing out of it is that these semantic versioned packages should all be accessible from your code, when you upgrade the package you don't automatically start calling the new version of the functions but instead get access to those functions along with all the previous releases. But that is a lot of extra information to add to every function call:

   @Package(arg, 1.4.2) foo(string i, int s) ...

1. https://www.youtube.com/watch?v=oyLBGkS5ICk&feature=youtu.be

On Thursday, 15 June 2017 at 18:02:54 UTC, Moritz Maxeiner wrote:
>> We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII).
> Not sure what exactly you are expecting, tbh.

I'm not advocating for a language change here.
As I said, we already have some deterministic destruction (the rest being the GC).

> Why are you even talking about the GC when your problem seems to require deterministic lifetime management. That's not what a GC does, and thus it's the wrong tool for the job.

I don't have a programming problem ; I'm fine with unique and scoped!

I just wanted to make a point about how even GC-languages still benefit from some extra automatic and deterministic means of resource management.

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

For those who say that this idea can't go anywhere without an idea of what changes it would make, I'll relink to the page I already posted.  There are many proposals that were rejected due to "breaking changes" that should be relooked for D3.
https://wiki.dlang.org/Language_design_discussions

People who say they like D2 for "stability" don't need to worry.  What would be a threat to stability is breaking changes in D2.  But that was never allowed, so you must not worry.  If D3 was released, you may still use D2 just as you would have otherwise.

For the people who talk about D3 being an alternative to, rather than a replacement for D2:
I think that D3 should seek to be a better option than D2 for virtually every new project.  If done right, it will barely split the community; I'm hoping for D3 to expand the popularity of D to overshadow what D2 ever was.  Improving some things in D would make it an easier sell to C++ programmers, even in converting existing projects.  What I think should be one of, if not the #1, main goal of D3 is to significantly shrink the number of scenario's in which C++ is more viable than D (to less than one third. Not "more viable" in the opinions of the D fanatics here, but to everyone who properly considers D vs C++.  I feel like D only needs one more major (breaking) revision to do this, and it would be a less dramatic change than D1-D2.

For those who are saying that everything is right with D2, I want to point out that there is a bias to the people in this forum.  It is that people posting here tend to be "insiders", who don't mind/see the problems that discourage others from using D.  There are surely many "outsiders" out there (not reading this) who have considered D in the past, but chose C++ instead for valid reasons.
I recommend searching the internet for others opinions on D.  You may find disadvantages of D apparent to other programmers that you never thought of.  Have you ever talked to a C++ programmer about what they think of D, and why they don't use it?

Also, I must say that although D is often discussed as a "systems programming language", I also have high hopes for it as an application programming language.  Once it's more widely supported, it can significantly lower the barrier-of-entry for programming.  People naturally gifted at programming probably don't realize how ridiculously high the barrier of entry is for most people, even those who are interested.

I hope that Walter and Andrei give a proper response to this thread.  I wonder why they haven't.

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)

On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
> I hope that Walter and Andrei give a proper response to this thread.  I wonder why they haven't.

They rarely give definitive answers... except after the fact, once it is already in master.