Kapps:

> That code is not @nogc safe, as you're creating a dynamic array within it. The fact that LDC2 at full optimizations doesn't actually allocate is simply an optimization and does not affect the design of the code.

I've added the opposite of what you say in the DIP. So Walter can fix it if it's wrong, or leave it there if it's right, because that DIP can't miss to to specify one behavour or the other:
http://wiki.dlang.org/DIP60

Bye,
bearophile

On 2014-04-17 17:29:02 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote:
>> People who care would go to the effort of manually marking weak references.
> 
> And that's not compatible with having a guarantee of memory safety.

Auto-nulling weak references are perfectly memory-safe. In Objective-C you use the __weak pointer modifier for that. If you don't want it to be auto-nulling, use __unsafe_unretained instead to get a raw pointer. In general, seeing __unsafe_unretained in the code is a red flag however. You'd better know what you're doing.

If you could transpose the concept to D, __weak would be allowed in @safe functions while __unsafe_unretained would not. And thus memory-safety is preserved.

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

On Thu, Apr 17, 2014 at 05:34:34PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/17/2014 5:09 PM, H. S. Teoh via Digitalmars-d wrote:
> >I thought that whole point of *A*RC is for the compiler to know when ref count updates can be skipped? Or are you saying this is algorithmically undecidable in the compiler?
> 
> I don't think anyone has produced a "sufficiently smart compiler" in that regard.

So what are some optimizations that compilers *are* currently able to do, and what currently isn't done?


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455

Would @nogc apply to code being evaluated at compile-time? I
don't think it should.

On Thursday, 17 April 2014 at 22:10:00 UTC, Walter Bright wrote:
> That pretty much kills it, even at 10%.

It probably is better than C++ shared_ptr though... D  can probably do better than objective-c with whole program compilation, since the dynamic aspects of objective-c methods are challenging.

On 4/17/2014 7:24 PM, H. S. Teoh via Digitalmars-d wrote:
> So what are some optimizations that compilers *are* currently able to
> do, and what currently isn't done?

Just look at all the problems with "escape analysis" being done with compilers.

On 4/17/2014 6:58 PM, Michel Fortin wrote:
> Auto-nulling weak references are perfectly memory-safe. In Objective-C you use
> the __weak pointer modifier for that. If you don't want it to be auto-nulling,
> use __unsafe_unretained instead to get a raw pointer. In general, seeing
> __unsafe_unretained in the code is a red flag however. You'd better know what
> you're doing.
>
> If you could transpose the concept to D, __weak would be allowed in @safe
> functions while __unsafe_unretained would not. And thus memory-safety is preserved.

I recall our email discussion about implementing ARC in D that we couldn't even avoid an inc/dec for the 'this' when calling member functions. So I don't see how inc/dec can be elided in sufficient numbers to make ARC performant and unbloated.

Of course, you can always *manually* elide these things, but then if you make a mistake, then you've got a leak and memory corruption.

On Friday, 18 April 2014 at 00:11:28 UTC, H. S. Teoh via Digitalmars-d wrote:
> I thought that whole point of *A*RC is for the compiler to know when ref
> count updates can be skipped? Or are you saying this is algorithmically
> undecidable in the compiler?

Multithreading cause major problems. A function owns the array passed as a parameter, no ref counting needed, but if another thread is deleting objects in the array then you cannot assume that ownership is transitive and will have to inc/dec every object you look at. If it is thread local then ownership is transitive and no inc/decs are needed in the function...?

But how can you let the compiler know that you have protected the array so only one thread will take processing-ownership during the life span of the function call?

On 4/17/2014 9:23 PM, Brad Anderson wrote:
> Would @nogc apply to code being evaluated at compile-time? I
> don't think it should.

Yes, it would be. Compile time functions are not special, in fact, there is no such thing in D.

On Friday, 18 April 2014 at 06:35:33 UTC, Walter Bright wrote:
> On 4/17/2014 9:23 PM, Brad Anderson wrote:
>> Would @nogc apply to code being evaluated at compile-time? I
>> don't think it should.
>
> Yes, it would be. Compile time functions are not special, in fact, there is no such thing in D.

But surely something like:

struct S
{
     this(int d) { data = d; }
     S opBinary(string op)(S rhs) @nogc
     {
       return S(mixin("data "~op~" rhs.data"));
     }

     private int data;
}

Would still work, right? There is no GC activity there.