DIP60: @nogc attribute

[Steven Schveighoffer via Digitalmars-d]

On Tue, 22 Apr 2014 09:48:28 -0400, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:

> On Tuesday, 22 April 2014 at 13:39:54 UTC, Steven Schveighoffer wrote:
>> On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad Can you explain  
>> this?
>
> When you use a C/C++ framework you don't know what happens to the  
> pointers you hand to it.

Those are typically well-documented, but yes, you rely on "insider"  
knowledge. You can mark C functions with the appropriate attributes so the  
D compiler can enforce this for you. I think we should make reference  
counting work, as long as you don't call mischievous library code. We take  
a similar approach to other safety aspects of D.

> You also don't know which threads call your D-functons from that  
> framework. (Assuming the framework is multi-threaded). To know this you  
> are required to know the internals of the framework you are utilizing or  
> inject runtime guards into your D functions?

Or just mark those objects sent into the framework as shared. Having  
multi-threaded RC isn't bad, just not as efficient.

One thing that would be nice is to allow moving a data pointer from one  
thread to another. In other words, as long as your data is contained, it  
can pass from one thread to another, and still be considered unshared.

I think sooner or later, we are going to have to figure that one out.

>
>> By mistake? How?
>
> By insertion into a global datastructure that happens at a lower layer  
> than the higher level you allocate on.

I think this is what you are talking about above, or is there something  
else?

-Steve