On 20/11/2021 2:37 AM, Ola Fosheim Grøstad wrote:
> On Friday, 19 November 2021 at 12:45:45 UTC, rikki cattermole wrote:
>> I'm more in favor of ARC completely. Tie it into scope, and the compiler can elide the calls. Add an operator overload so that you can get a non-scope reference to memory and it might be a very nice situation for us.
> 
> That is more conventional, and in some sense easier because it is more homogeneous.
> 
> I think some people will complain about performance, but I am not against it.

For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.

But yeah, a fiber aware GC that could clean things up as it goes along would be absolutely amazing for stuff like web development.

On 20/11/2021 2:21 PM, Ola Fosheim Grøstad wrote:
> On Saturday, 20 November 2021 at 00:55:36 UTC, rikki cattermole wrote:
>> For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.
> 
> Yes. Regardless, ARC requires more compiler restructuring.

To me ARC is just what we have now with a couple of compiler hooks. So it shouldn't need restructuring for this.

> Right now regular RC + local GC is the easy implementation...
> 
> But regular RC is not convincing anyone, sigh...

I use it, but it is expensive, I know this. But it is the only way to make the resources go away guaranteed (unless something messes with the thread state).

However a lot of the usage of the RC could work with scope and possibly even const. So there is a lot of potential easy optimizations being missed due to the fact that we don't have the methods to call specifically for RC.

I.e.

void someFunc(scope RCData data) {
	someOtherFunc(data);
}

At no point from that point forward would RC methods need to be called. But copy constructors, postblit and destructors would need to be called regardless on a struct. Its a real shame.

On 20/11/2021 4:27 PM, Ola Fosheim Grøstad wrote:
> I had an idea for a LLVM hack, but Apple ARC engineers pointed out that there were issues to me so I consider that to be unworkable. Meaning: I trust their experience. So you have to do it over a suitable high level IR. I don't think D has that... At least not to my knowledge.

Yeah, the DFA probably does get gnarly beyond certain patterns.

And truth be told I think we *do* need to build that IR at some point, because right now with the return ref and all those attributes its just garbage that humans have to write that rather than letting the compiler figure it out.

On Saturday, 20 November 2021 at 03:38:01 UTC, rikki cattermole wrote:
> And truth be told I think we *do* need to build that IR at some point, because right now with the return ref and all those attributes its just garbage that humans have to write that rather than letting the compiler figure it out.

The compiler already does figure most of it out. That's how it can emit compile time error messages for missing or incorrect attributes, or implementation violations of an attribute's guarantees. The attributes exist primarily for two reasons:

1) To verify programmer intent, that the inferred attributes of the code written match the intended attributes.

2) To specify APIs independent of implementation, for `extern` linking, `interface`s and base `class`es with multiple implementations that might imply different attributes, etc.

Attribute soup is unavoidable for (2) public APIs in general; there is nowhere else the information *can* come from in many cases except from an explicit specification, regardless of how sophisticated the compiler is.

Redundant specification of attributes for (1) verification purposes could be dropped, but I'd rather not since I find the compiler frequently catches mistakes or fuzzy thinking on my part by comparing explicit attributes to inferred.