On 2013-10-09 17:36:01 +0000, Johannes Pfau <nospam@example.com> said:

> Am Wed, 9 Oct 2013 13:13:51 -0400
> schrieb Michel Fortin <michel.fortin@michelf.ca>:
> 
>> On 2013-10-09 16:51:03 +0000, Manu <turkeyman@gmail.com> said:
>> 
>>> On 10 October 2013 01:40, Johannes Pfau <nospam@example.com> wrote:
>>> 
>>>> But if someone really wants to strip the GC _completely_ there's a
>>>> huge issue with memory management of Exceptions.
>>> 
>>> Exceptions have a pretty well defined lifetime... can't they be
>>> manually cleaned up by the exception handler after the catching
>>> scope exits?
>> 
>> Exceptions don't need a well-defined lifetime for things to work.
> 
> What I meant was using exceptions without the GC requires huge changes
> (like switching all exceptions to use reference counting) or at least
> using the same type of allocation for all exceptions. If you have
> 'malloced' and GC owned exceptions it can be hard to know if an
> Exception needs to be freed:
> 
> try
> {
>     codeWithMallocException();
>     codeWithGCException();
> }
> catch(Exception e)
> {
>     //Am I supposed to free this exception now?
> }

Sorry. I think I got mixed up in different branches of this huge discussion thread. This branch is about having a separate attribute to split ref-counted objects from GC objects, but having the two coexist. Other branches are about replacing the GC with a ref-counted GC, but that's not what we're talking about here.

You are perfectly right that you can't mix GC exceptions with ref-counted exceptions. And if ref-counted exceptions can't derive from the garbage collected Exception class, then it becomes awfully complicated (probably impossible) to have exception without having the GC cleaning them up.

I was wrong, that's an issue. It's no different than the general issue that you need to have a separate root class however. You simply need a separate root exception class too, one that you'd have to catch explicitly and that catch (Exception e) would not catch. That's not very practical.

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

On 2013-10-09 19:10, Andrei Alexandrescu wrote:

> Again: USER CODE SHOULD HAVE NO BUSINESS CASTING CASUALLY TO GET WORK DONE.

I agree. Doesn't "new shared(X)", or something like that, already work?

-- 
/Jacob Carlborg

On 10/9/13 6:38 AM, Michel Fortin wrote:
> Walter's idea was to implement ARC for classes implementing IUnknown. So
> if you wanted a ARC'ed class, you implement IUnknown and you're done.
> Problems were on the edges of ARC-controlled pointers and GC-controlled
> ones (which cannot be allowed to be mixed), and also with wanting to use
> the GC to free cycles for these objects (which would make COM AddRef and
> Release unusable when called from non-D code). I think the only way to
> make that work sanely is to create another root object for ref-counted
> classes.

Agreed. This summary reveals the major difficulties involved.

> Another idea was to make *everything* in D ref-counted. ARC simply
> becomes another GC implementation. There can be no confusion between
> what's ref-counted and what isn't (everything is). It's much simpler
> really. But Walter isn't keen on the idea of having to call a function
> at every pointer assignment to keep the reference count up to date (for
> performance reasons), so that idea was rejected. This makes some sense,
> because unlike Objective-C ARC where only Objective-C object pointers
> are ref-counted, in D you'd have to do that with all pointers, and some
> will point to external data that does not need to be ref-counted at all.

I don't think that's on the reject list. Yah, call a function that may either be an inline lightweight refcount manipulation, or forward to a virtual method etc. It's up to the class.

> It was also pointed out that concurrent GCs require some work to be done
> on pointer assignment (and also when moving a pointer). So it seems to
> me that advances on the GC front are going to be limited without that.
>
> And now, things seems to have stalled again. It's a little disappointing.

I don't think we're stalled.


Andrei

On 10/9/2013 7:11 AM, Dicebot wrote:
> 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 would generally agree with that.

On 10/09/2013 05:38 AM, Andrei Alexandrescu wrote:
> On 10/8/13 4:22 PM, Sean Kelly wrote:
>> ...
>>
>> And we already have a forest of attributes on otherwise ordinary
>> functions.
>
> It's the cost of expressiveness. Exercising deduction wherever possible
> is the cure.
>
> Andrei
>

The cost of expressiveness certainly is not tedious syntax. What he outlines is a cost of lacking expressiveness. (Eg. it is impossible to abstract over lists of built-in attributes.)

On Wednesday, October 09, 2013 06:57:00 Sean Kelly wrote:
> 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.

We'd probably do a lot better if we had better defaults (e.g. default to pure and then have an attribute for impure instead). The attributes that we have were formed around adding to what's in C/C++ rather than around minimizing the number of attributes required on your average function. But unfortunately, it's too late for that now, given how much code it would break to change it.

- Jonathan M Davis

On 2013-10-09 18:14:31 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

>> Another idea was to make *everything* in D ref-counted. ARC simply
>> becomes another GC implementation. There can be no confusion between
>> what's ref-counted and what isn't (everything is). It's much simpler
>> really. But Walter isn't keen on the idea of having to call a function
>> at every pointer assignment to keep the reference count up to date (for
>> performance reasons), so that idea was rejected. This makes some sense,
>> because unlike Objective-C ARC where only Objective-C object pointers
>> are ref-counted, in D you'd have to do that with all pointers, and some
>> will point to external data that does not need to be ref-counted at all.
> 
> I don't think that's on the reject list. Yah, call a function that may either be an inline lightweight refcount manipulation, or forward to a virtual method etc. It's up to the class.

Are we talking about the same thing? You say "it's up to the class", but it should be obvious that *everything* being reference counted (as I wrote above) means every pointer, not only those to classes. Having only classes being reference counted is not very helpful if one wants to avoid the garbage collector.

And that discussion with Johannes Pfau a few minutes ago about exceptions shows that if you disable the GC, exceptions can't depend on the GC anymore to be freed, which is a problem too. (Should we create another ref-counted exception root type? Hopefully no.)

In my opinion, trying to segregate between reference-counted and garbage-collected types just makes things awfully complicated. And it doesn't help much someone who wants to avoid the GC. To be useful, reference counting should be a replacement for the garbage collector (while still keeping the current GC to free cycles).

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

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.


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

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

On Wednesday, 9 October 2013 at 08:05:30 UTC, Andrei Alexandrescu wrote:
> I'm hesitant about stuff that computes function summaries such as __traits(getFunctionsCalled, function) without allowing those summaries to make it into the function's signature or attributes. It makes separate compilation difficult.

That's the verification of the attribute. You can still attach the attribute to a prototype without a body for separate compiliation (this is the same as @safe - the prototype could be lying and the compiler can't verify, but you trust the annotation is correct).

The advantage __traits(getFunctionsCalled) has over a built-in @nogc is simply that we can define it all in the library, and add more, combine ones*, etc., without changing the language again.

* A library uda could be defined to check @everything || @nogc or whatever, since it is ultimately implemented as a static assert which can do it all too.