February 02, 2014
Agreed. We must keep the GC in D and not change its semantics (certainly its performance to be sure).

I would not even want to go the Rust way (their latest anyway, it keeps changing, mostly for the better) of relegating the GC to a library type Gc<T>. It should remain part of the language for the majority of developers who benefit from it.

Again, I agree, making life harder for people who wish to use GC would not be acceptable. I enjoy the GC for non-critical apps.

What I am for is an opt-in solution for GC, not necessarily, as the OP implies, favoring smart pointers over GC, but for both being on an equal footing.

Let developers who strive for ultimate performance choose their tool and let D set the standard for what is possible with a modern language.

It might be a minority issue overall, but a significant one here in these forums, from what I gather.

The D implementers will decide if the two ways of memory management can be reconciled and if it's worth the effort. +1 from me on both.
February 02, 2014
On Sat, 01 Feb 2014 18:16:07 -0800, Frank Bauer <y@z.com> wrote:

> Agreed. We must keep the GC in D and not change its semantics (certainly its performance to be sure).
>
> I would not even want to go the Rust way (their latest anyway, it keeps changing, mostly for the better) of relegating the GC to a library type Gc<T>. It should remain part of the language for the majority of developers who benefit from it.
>
> Again, I agree, making life harder for people who wish to use GC would not be acceptable. I enjoy the GC for non-critical apps.
>
> What I am for is an opt-in solution for GC, not necessarily, as the OP implies, favoring smart pointers over GC, but for both being on an equal footing.
>
> Let developers who strive for ultimate performance choose their tool and let D set the standard for what is possible with a modern language.
>
> It might be a minority issue overall, but a significant one here in these forums, from what I gather.
>
> The D implementers will decide if the two ways of memory management can be reconciled and if it's worth the effort. +1 from me on both.

I am for that as well. GC by default, then opt-in to other semantics, even if via new syntax. That will give the flexibility to do what you need to do when you need to do it without significantly increasing the costs to the common use case... THAT is a laudable position to take. And I'll happily root for support different resource management paradigms, because the one truth is that there is no one right way. But as soon as I start seeing arguments along the lines of "X is stupid because it doesn't work for my use case so we must replace it with Y" I'll start fighting.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 02, 2014
Yes, that would be stupid.
February 02, 2014
On Sunday, 2 February 2014 at 02:05:16 UTC, Manu wrote:
> On 2 February 2014 00:33, Frank Bauer <x@y.com> wrote:
>> ARC would be a plus for heavily interdependent code. But it doesn't beat
>> unique_ptr semantics in local use that free their memory immediately as
>> they go out of scope or are reassigned.
>
>
> Why wouldn't ARC do this?

Because in a local scope you could decide when to free the object at compile time (i.e. end of scope) and not drag a reference count around when it is not necessary?
February 02, 2014
Just to clarify: I would like to have the following pointers. I'll start with the GC ones to maybe reach some consensus quicker ;)

1. GC(T)
Pointer to a heap allocated T, garbage collected.

2. ARC(T)
Reference counted pointer to a heap allocated T, compiler manages lifetime automatically via retain/ release.

3. Owning(T)
Pointer to a heap allocated T, freed when pointer goes out of scope or is reassigned (some special interactions with Borrowed(T) on top of that).

4. Borrowed(T)
Pointer to a T, not necessarily heap allocated, has no impact on memory allocation/ deallocation of the T whatsoever, if assigned from an Owning(T) prevents that owning pointer from being freed or reassigned as long as the borrowed pointer is in scope.

Performance, or, should I say, meddling of the compiler and runtime in your code, is from worst to best.

We could argue over which pointer concepts would be granted the honor of receiving their own D definition syntax (new, ~, @, &, whatever).
February 02, 2014
Of course, the big deal is: if I opt for ARC(T), Owning(T) and Borrowed(T) exclusively, the GC has no business running for a microsecond in my code or the standard library functions I call.
February 02, 2014
On 2/1/14, 6:59 PM, Frank Bauer wrote:
> Just to clarify: I would like to have the following pointers. I'll start
> with the GC ones to maybe reach some consensus quicker ;)
>
> 1. GC(T)
> Pointer to a heap allocated T, garbage collected.
>
> 2. ARC(T)
> Reference counted pointer to a heap allocated T, compiler manages
> lifetime automatically via retain/ release.
>
> 3. Owning(T)
> Pointer to a heap allocated T, freed when pointer goes out of scope or
> is reassigned (some special interactions with Borrowed(T) on top of that).
>
> 4. Borrowed(T)
> Pointer to a T, not necessarily heap allocated, has no impact on memory
> allocation/ deallocation of the T whatsoever, if assigned from an
> Owning(T) prevents that owning pointer from being freed or reassigned as
> long as the borrowed pointer is in scope.
>
> Performance, or, should I say, meddling of the compiler and runtime in
> your code, is from worst to best.
>
> We could argue over which pointer concepts would be granted the honor of
> receiving their own D definition syntax (new, ~, @, &, whatever).

Whoa, this won't work without an explosion in language complexity.

Andrei

February 02, 2014
On Sat, 01 Feb 2014 19:15:38 -0800, Frank Bauer <y@z.com> wrote:

> Of course, the big deal is: if I opt for ARC(T), Owning(T) and Borrowed(T) exclusively, the GC has no business running for a microsecond in my code or the standard library functions I call.

That's not a guarantee that can be reasonably made or demanded. You have no idea if a library you are using is written using the GC and turning those on would have no way to impact the allocation scheme of the library. As long as there is a possibility of a GC, D will have to pass an active GC instance to any libraries that are loaded.

The GC only runs right now when a GC allocation is requested. I've been saying this all over the forums but people seem to persist in the mindset that the GC is a black-box that runs at completely random intervals, for random intervals, all determined by voodoo and black magic. It's not, and it doesn't. The GC only runs when an allocation is requested that cannot be filled from the current available heap. If you don't use the GC, by definition it will not run, unless a library you depend on uses it.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 02, 2014
On Sunday, 2 February 2014 at 03:38:08 UTC, Adam Wilson wrote:
> You have no idea if a library you are using is written using the GC.

Well, the library writer might tell me, if she used GC(T) (the linker might as well) ...

> If you don't use the GC, by definition it will not run, unless a library you depend on uses it.

big UNLESS!
February 02, 2014
On Sunday, 2 February 2014 at 03:38:03 UTC, Andrei Alexandrescu wrote:
> Whoa, this won't work without an explosion in language complexity.
>
> Andrei

Only daydreaming ...