On 10/9/2013 7:30 AM, Manu wrote:
> ARC. I've been here years now, and I see absolutely no evidence that the GC is
> ever going to improve. I can trust ARC, it's predictable, I can control it.
> Also, proper support for avoiding the GC without severe inconvenience as
> constantly keeps coming up. But I don't think there's any debate on that one.
> Everyone seems to agree.

I think we can get pretty close to ARC by using RefCounted, but you've indicated you disagree.

(Note that ObjC does not have a template system, and so using a library system was not possible for ObjC.)

On 10/9/2013 10:05 AM, Manu wrote:
> Supporting ARC in the compiler _is_ the job. That includes a cyclic-reference
> solution.

Wholly replacing the GC with ARC has some fundamental issues:

1. Array slicing becomes clumsy instead of fast & cheap.

2. Functions can now accept new'd data, data from user allocations, static data, slices, etc., with aplomb. Wiring in ARC would likely make this unworkable.

3. I'm not convinced yet that ARC can guarantee memory safety. For example, where do weak pointers fit in with memory safety? (ARC uses user-annoted weak pointers to deal with cycles.)

On 10/9/2013 4:57 AM, Jacob Carlborg wrote:
> On 2013-10-09 07:15, Manu wrote:
>
>> What I want is an option to replace the GC with ARC,
>
> We had an email conversation about ARC when I announced the updated Objective-C
> support for D. Perhaps it's time make it public. I don't think we came to a
> conclusion. I had some trouble following it. It was a bit too advanced for me.
>

If it's got valuable information in it, please consider making it public here (after getting permission from its participants).

On Wednesday, 9 October 2013 at 16:51:11 UTC, Manu wrote:
> Exceptions have a pretty well defined lifetime... can't they be manually
> cleaned up by the exception handler after the catching scope exits?

static Exception askingForTrouble;
try { ... } catch(Exception e) {
    askingForTrouble = e;
}

On 10/9/2013 12:26 PM, Walter Bright wrote:
> If it's got valuable information in it, please consider making it public here
> (after getting permission from its participants).

Eh, I see that I was on that thread. Am in the process of getting permission.

On Wednesday, 9 October 2013 at 18:41:21 UTC, Michel Fortin wrote:
> On 2013-10-09 17:15:51 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>
>> On 10/9/13 6:06 AM, Michel Fortin wrote:
>>> I don't know about you, but circular references are not rare at all in
>>> my code.
>> 
>> Nor Facebook's. I can't give away numbers, but the fraction of cycles per total memory allocated averaged over all of Facebook's PHP programs (PHP being reference counted) is staggering. Staggering!
>> 
>> If PHP didn't follow a stateless request model (which allows us to use region allocation and reclaim all memory upon the request's end), we'd be literally unable to run a server for more than a few minutes.
>
> Don't remind me. About 8 years ago I had to abandon a big PHP project simply because PHP couldn't deal with cycles. There was no way to scale the thing.

Solved in 5.3

Am 09.10.2013 17:40, schrieb Johannes Pfau:
>
> But if someone really wants to strip the GC _completely_ there's a huge
> issue with memory management of Exceptions.
>

I don't agree there. Basically all my catch blocks look like this:

catch(Exception ex)
{
  //do something with ex
  Delete(ex);
}

I never had problems with this, or memory leaks.

On 2013-10-09 19:45:39 +0000, "deadalnix" <deadalnix@gmail.com> said:

>> Don't remind me. About 8 years ago I had to abandon a big PHP project simply because PHP couldn't deal with cycles. There was no way to scale the thing.
> 
> Solved in 5.3

I know. 4 years tool late.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Wednesday, 9 October 2013 at 19:24:18 UTC, Walter Bright wrote:
> 1. Array slicing becomes clumsy instead of fast & cheap
>
> 2. Functions can now accept new'd data, data from user allocations, static data, slices, etc., with aplomb. Wiring in ARC would likely make this unworkable.

If we had working scope storage class, these could be solved - you could slice to your heart's content as long as the reference never escapes your current scope.

Really, I want this regardless of the rest of the discussion just because then we can boot a lot of stuff to the library.

I realize it is easier said than done, but I'm pretty sure it is technically supposed to work already...

On Wednesday, 9 October 2013 at 18:44:16 UTC, dennis luehring wrote:
> Am 09.10.2013 16:11, schrieb Dicebot:
>> On Wednesday, 9 October 2013 at 13:57:03 UTC, Sean Kelly wrote:
>>> They aren't opt-out for really any reasonable project though,
>>> because code is reused and those people may want at least the
>>> standard attributes to be set. Personally, the array of
>>> attributes that can be applied to a D function is one of my
>>> biggest pet peeves with the language. It gains me nothing
>>> personally, and adds a lot of extra thought to the process of
>>> writing a function.
>>
>> This is exactly what I was speaking about. It would have been
>> much more easy if stuff was `pure @safe immutable nothrow` by
>> default and one added `dirty @system mutable throw` on per-need
>> basis after getting compiler error. But that is too late to
>> change and this attribute inference may be only reasonable option.
>>
>
> i wouldn't say that - lets talk about D3 or even D4 - with breaking changes or else the language development will come to a full stop in a few months/years, if something is totaly wrong it needs to be addressed and changed, developers will follow

Would it be possible to specify at the file level (or for a section of the file) a set of default attributes, and then override those for individual functions if need be?  I am not sure what the syntax would look like, but say it would be:

attributes @safe pure nothrow

Then every function has these attributes, unless otherwise specified. You could even possibly use more than once to divide up you code into sections with common attributes.

attributes @safe pure nothrow

//Everything defined here is @safe pure nothrow

attributes @system

//Everything defined below this invocation is @system by default
//and so forth