On 09.10.2013 14:41, Dicebot wrote:
> On Tuesday, 8 October 2013 at 22:02:07 UTC, Peter Alexander wrote:
>> Just learn where allocations occur and avoid them during development.
>> This leaves you only with accidental or otherwise unexpected allocations.
>
> D is not expected to be a single man project language, isn't it? As I
> have already said, this implies spending plenty of time on careful
> reviewing of something that compiler can detect.

+1

We are humans that make mistakes. This is normal. Compilers are here to help us talk to the computers.

On 2013-10-09 04:07:53 +0000, "deadalnix" <deadalnix@gmail.com> said:

> That being said, isolated is probably something we want to add in the future.

You'll hit a problem with immutable though. Immutable is implicitly shared, and immutable strings are everywhere!

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

On 2013-10-09 07:33:29 +0000, Manu <turkeyman@gmail.com> said:

> Is there more to it? Cleaning up circular references I guess... what does
> Apple do?

Apple implemented auto-nulling weak pointers for ARC (as well as __unsafe_unretained ones if you are not afraid of dangling pointers).

> It's an uncommon edge case, so there's gotta be heaps of room for efficient
> solutions to that (afaik) one edge case. Are there others?

I don't know about you, but circular references are not rare at all in my code.

Another solution that could be used for circular references is to have the stop-the-world GC we have now collect them. Reference counting could be used to free GC memory in advance (in the absence of circular references), so the GC would have less garbage to collect when it runs.

Both solutions (week-autonulling and last-resort GC) are not mutually exclusive and can coexist.

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

On 2013-10-09 11:58:33 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-10-09 09:33, Manu wrote:
> 
>> It sounds pretty easy to reach to me. Compiler generating inc/dec ref
>> calls can't possibly be difficult. An optimisation that simplifies
>> redundant inc/dec sequences doesn't sound hard either... :/
>> Is there more to it? Cleaning up circular references I guess... what
>> does Apple do?
>> It's an uncommon edge case, so there's gotta be heaps of room for
>> efficient solutions to that (afaik) one edge case. Are there others?
> 
> See my reply to one of your other posts:
> 
> http://forum.dlang.org/thread/bsqqfmhgzntryyaqrtky@forum.dlang.org?page=10#post-l33gah:24ero:241:40digitalmars.com

I 
> 
> don't recall the exact issues but there were several issues that were brought up in the email conversation.

Here's a quick summary:

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.

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.

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.

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

On Oct 9, 2013, at 5:48 AM, "Dicebot" <public@dicebot.lv> wrote:
> 
>> On Tuesday, 8 October 2013 at 23:22:54 UTC, Sean Kelly wrote: On Oct 8, 2013, at 3:38 PM, Walter Bright
>>> This, of course, is the other problem with @nogc. Having a forest of attributes on otherwise ordinary functions is awfully ugly.
>> 
>> And we already have a forest of attributes on otherwise ordinary functions.
> 
> I don't understand why there is such reluctance to have many attributes. I'd gladly accept language with literally hundreds of those if they are orthogonal and useful. That is the very point of using strong typed language - making compiler verify as much assumptions as possible for you. Key problem here is not amount of attributes but that those are opt-in, not opt-out,

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.

Am Wed, 9 Oct 2013 09:38:12 -0400
schrieb Michel Fortin <michel.fortin@michelf.ca>:

> 
> I think the only way to make that work sanely is to create another root object for ref-counted classes.
> 

The problem here is we need a way to know that type X is refcounted, right? Couldn't we just use an attribute with the class or interface declaration:

@refcounted interface X{};
@refcounted class Y {};
class X1 : X;
class Y1 : Y;

Now we know for sure that all these classes and SubClasses are refcounted.

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

The GC should be integrated with ARC types. A generic solution could be
allowing different allocators with ARC types:
auto a = new!Malloc RefCountedClass();
auto b = new!GC RefCountedClass();
auto c = new!Pool RefCountedClass();

This can be done by storing a hidden pointer to the free function in every @refcounted class and the GC's free function is then just a no-op.

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.

On Wednesday, 9 October 2013 at 14:11:46 UTC, Dicebot wrote:
> 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.

Maybe it's worth to introduce "pure: @safe: immutable: nothrow:" on top of every module as the new recommended design pattern. Will it work?

Then it may go through a deprecation phase, e.g. omitting it on top of the module becomes a warning, then an error, then it becomes the default.

On Oct 9, 2013, at 4:30 AM, Jacob Carlborg <doob@me.com> wrote:
> 
>> On 2013-10-09 05:31, Walter Bright wrote:
>> 
>> Making this work is fraught with difficulty. It is normal behavior in D to create local data with new(), build a data structure, and then cast it to shared so it can be transferred to another thread. This will fail miserably if the data is allocated on a thread local heap.
> 
> I agree with Andrei here. Alternatively perhaps the runtime can move the data to a global pool if it's casted to shared.

Generally not, since even D's precise GC is partially conservative.  It's also way more expensive than any cast should be. For better or worse, I think being able to cast data to shared means that we can't have thread-local pools. Unless a new attribute were introduced like "local" that couldn't ever be cast to shared, and that sounds like a disaster.

On 2013-10-09 15:51, Sean Kelly wrote:

> Generally not, since even D's precise GC is partially conservative.  It's also way more expensive than any cast should be. For better or worse, I think being able to cast data to shared means that we can't have thread-local pools. Unless a new attribute were introduced like "local" that couldn't ever be cast to shared, and that sounds like a disaster.

Since casting breaks the type system to begin with and is an advanced feature. How about providing a separate function that moves the object? It will be up to the user to call the function.

-- 
/Jacob Carlborg