On 30/05/2022 1:04 AM, Ola Fosheim Grøstad wrote:
> On Sunday, 29 May 2022 at 12:57:01 UTC, rikki cattermole wrote:
>> side of decisions, whereas I'm more interested in complimentary since I have to stick to things like -betterC.
> 
> ARC could work with -betterC.

I'm convinced for structs and classes, that's actually a DIP I would like to write. I have written a bit up about what it would be[0].

Without boxing into fat types, I don't see how its going to be possible. The boxing I'm really not happy about, as that is changing known type behaviors and properties which is concerning to me.

But hey, I'd love to be proven wrong (not that I've thought about this much)!

[0] https://gist.github.com/rikkimax/95994607813d6665b6adbfb36d180c42#file-opref-md

On 5/28/2022 5:22 PM, Rikki Cattermole wrote:
> 1. Inferred for anything non-virtual

dip1000 infers `scope` and `return` for:

1. templates
2. lambdas
3. nested functions
4. generated functions

i.e. where the source to the function is there.

But this isn't so for:

  int* foo(int*);

where the declaration of foo() is separated (maybe in another file) from its definition.

Your proposal requires all the source to be available, and no "header" declarations. It also won't work for pointers to functions and delegates.

To make those work will require annotations - the same reason D has `scope` and `return` annotations.

On 30/05/2022 8:26 AM, Walter Bright wrote:
> where the declaration of foo() is separated (maybe in another file) from its definition.
> 
> Your proposal requires all the source to be available, and no "header" declarations. It also won't work for pointers to functions and delegates.
> 
> To make those work will require annotations - the same reason D has `scope` and `return` annotations.

Indeed.

I don't think you can get around having annotations for lifetime stuff for function pointers or virtual methods. You simply are going to need them.

Here is a common bit of code I've got:

```d

struct Thing {
@safe nothrow @nogc:

    StringBuilder_ASCII toString(RCAllocator allocator = globalAllocator()) @trusted scope {
        StringBuilder_ASCII ret = StringBuilder_ASCII(allocator);

        ...

        return ret;
    }
}
```

The fact that it is called toString is immaterial (just want to point that out).

There are two sets of function annotations, at the struct scope level and at the method level. Scope on the method should actually be at the struct level, its not due to[0]. So we can ignore that one as it is unrelated to the problem at hand.

But the @trusted on the other hand, that is DIP1000 related. Since without it, DIP1000 is seeing ret and even though the this pointer and anything in it, is not stored in anyway inside of ret, ret is inferred as scope and cannot be returned.

While I'm sure we can special case this to get it to work, this is a pretty good example of where things that should be working right now, are not.

I know in my original post I didn't talk about how to turn this sort of thing on, in the past I used scope as a type qualifier to do it in my thought experiments. Which would work in all D code regardless of function annotations.

[0] https://issues.dlang.org/show_bug.cgi?id=23142

On 5/29/2022 4:56 PM, rikki cattermole wrote:
> [0] https://issues.dlang.org/show_bug.cgi?id=23142

Thanks for the report, but I don't understand what it has to do with the rest of your post?

On 30/05/2022 2:00 PM, Walter Bright wrote:
> On 5/29/2022 4:56 PM, rikki cattermole wrote:
>> [0] https://issues.dlang.org/show_bug.cgi?id=23142
> 
> Thanks for the report, but I don't understand what it has to do with the rest of your post?

Its basically the only non-design related issue I've encountered when working with compiler guarantees in the last year or so.

So its worth the mention since it only comes up because I'm using DIP1000 with all the attribute soup that goes along with it.