February 25

On Tuesday, 25 February 2025 at 00:17:19 UTC, Jonathan M Davis wrote:

>

As for RefCounted specifically, I haven't looked at its implementation recently, so I don't know why it can't be @safe, but off the top of my head, I don't see why it can't be possible to create something like RefCounted that is @safe.

I had another look at it, and my conclusion is, it actually doesn't require DIP1000. DIP25 is enough! If you don't recall, and if I understand it correctly DIP25 is essentially DIP1000 limited only to ref and return ref. scope/return scope rules for pointers/slices/classes/struct/unions aren't included. It's already the default in the current language.

Now, it's still possible to escape the payload with the same tricks you could escape a pointer to stack in default D. But this will also be fixed if we implement Simple Safe D. DIP1000 is not strictly needed for this use case. Although in Simple Safe D the user will likely have to make temporary copies of the payload, or parts of it, that would be unneeded in present D or with DIP1000 - just like when dealing with objects on the stack.

March 05

On Tuesday, 25 February 2025 at 11:46:44 UTC, Dukc wrote:

>

If you don't recall, and if I understand it correctly DIP25 is essentially DIP1000 limited only to ref and return ref. scope/return scope rules for pointers/slices/classes/struct/unions aren't included. It's already the default in the current language.

How does this compare with a similar mechanism in C#, which seems to have something akin to scoped pointers?

See the postscript in the below article, where this was added as a means of working around limits in C#'s existing "borrow checking", and preventing escapes.

https://em-tg.github.io/csborrow/

That brought to mind this discussion, and hence wondering if there are any answers there to be "stolen", since to my ignorant first glance it seems similar to what D is groping towards with DIP 1000.

March 05

On Wednesday, 5 March 2025 at 22:04:24 UTC, Derek Fawcus wrote:

>

That brought to mind this discussion, and hence wondering if there are any answers there to be "stolen", since to my ignorant first glance it seems similar to what D is groping towards with DIP 1000.

Yes indeed. This goes to show dip1000's aim is the right one, just needs more convenient usage.

Thanks for sharing.

March 06

On Wednesday, 5 March 2025 at 22:27:32 UTC, Sebastiaan Koppe wrote:

>

On Wednesday, 5 March 2025 at 22:04:24 UTC, Derek Fawcus wrote:

>

That brought to mind this discussion, and hence wondering if there are any answers there to be "stolen", since to my ignorant first glance it seems similar to what D is groping towards with DIP 1000.

Yes indeed. This goes to show dip1000's aim is the right one, just needs more convenient usage.

Thanks for sharing.

Here is another article which touches on the same areas, and may be of interest:

https://btmc.substack.com/p/borrow-checking-from-scratch

March 06

On Wednesday, 5 March 2025 at 22:04:24 UTC, Derek Fawcus wrote:

>

On Tuesday, 25 February 2025 at 11:46:44 UTC, Dukc wrote:

>

If you don't recall, and if I understand it correctly DIP25 is essentially DIP1000 limited only to ref and return ref. scope/return scope rules for pointers/slices/classes/struct/unions aren't included. It's already the default in the current language.

How does this compare with a similar mechanism in C#, which seems to have something akin to scoped pointers?

See the postscript in the below article, where this was added as a means of working around limits in C#'s existing "borrow checking", and preventing escapes.

https://em-tg.github.io/csborrow/

DIP25 is pretty similar to this, except it can also specify non-returning references.

DIP1000 is more advanced, though. It works not only with references, but also with pointers, arrays, structs and so on. Meaning you can pass a slice of a static array on the stack to a function, and it will be checked for escaping just like a ref parameter would. DIP25 can't do that, and I think the C# equivalent neither can.

Another thing DIP1000 enables over DIP25 is a reference to a scoped pointer (or slice, or struct, or class), meaning you can have a function that mutates a pointer to a local variable in place . From my post in the official blog:

@safe ref Exception nullify(return ref scope Exception obj)
{
    obj = null;
    return obj;
}

@safe unittest
{
    scope obj = new Exception("Error!");
    assert(obj.msg == "Error!");
    obj.nullify;
    assert(obj is null);
    // Since nullify returns by ref, we can assign
    // to it's return value.
    obj.nullify = new Exception("Fail!");
    assert(obj.msg == "Fail!");
}

. The exception obj points to in the unit test is allocated on the stack because of scope, yet nullify can mutate the class reference in place (as opposed to only the class itself). You can't do this safely with DIP25 alone, since you can't have a ref to another ref.

1 2
Next ›   Last »