On 10.04.22 17:04, Alexandru Ermicioi wrote:
> On Friday, 8 April 2022 at 18:00:14 UTC, rikki cattermole wrote:
>> Here is my test code that I used to determine what I needed to do to make const RC types useless (and hopefully safe).
>> ...
> 
> Isn't better then to try and find design patterns or rules for use with mutable RC structures?
> 
> All the talk across the years was basically about trying to eat the pancake and also at same time trying to keep it for later, and neither is done after all deliberation across the years. Perhaps it would be best to just break the existing immutable system, and redefine it to allow rc features found in C++ or other languages, or just have a limited version of rcs in D (compared to C++ or other languages employing them), and workaround those restrictions through some well defined rules and design patterns.
> 
> And when mentioning breaking the immutable system, I really mean breaking it, by removing the transitiveness it has, or some other major change, like not being really immutable, and therefore safe to put in readonly memory.
> 
> 

I think the solution of this particular issue should come down to one of:

- accept that `immutable` means immutable, only use it where it actually makes sense to enforce that restriction, derive valid compiler optimizations from a specification based on UB. No immutable RC is allowed. `immutable` values can always be put in readonly memory, simple story for CTFE accessing immutable values.

- accept that there could potentially be mutable parts in `immutable` structures exclusively for low-level purposes, separate `immutable` and `shared immutable`, explicitly specify valid compiler optimizations based on nondeterministic semantics. Immutable RC is a thing. Whether or not `immutable` values can be put in readonly memory depends on the particular type, more complicated story for CTFE accessing immutable values.

Anyway, this is by far not the only issue with qualifiers applied to user-defined types. Built-in slices and pointer types have magical interactions with qualifiers that user-defined types cannot reproduce.

On 11/04/2022 3:04 AM, Alexandru Ermicioi wrote:
> Isn't better then to try and find design patterns or rules for use with mutable RC structures?

Yes.

But if the compiler allows RC to become const and not allow RC to occur, that is a bad situation to be in...

That is what my test code above does, it prevents you from using it with const as much as possible.

It is a workaround to a much larger problem.

On Sunday, 10 April 2022 at 23:12:03 UTC, rikki cattermole wrote:
>
> On 11/04/2022 3:04 AM, Alexandru Ermicioi wrote:
>> Isn't better then to try and find design patterns or rules for use with mutable RC structures?
>
> Yes.
>
> But if the compiler allows RC to become const and not allow RC to occur, that is a bad situation to be in...

This seems like a couple of edge cases and bugs that need to be rectified, in order to have proper safe mutable only RC structs. You should be able to disallow implicit cast to const of struct if it is desired to do so.

>
> That is what my test code above does, it prevents you from using it with const as much as possible.
>
> It is a workaround to a much larger problem.

Regarding const rc use, I think there can be a limited access to the payload, if you somehow prohibit taking the address of the payload or it's sub-elements. Perhaps instead of returning payload itself from rc struct, maybe it can be wrapped into a wrapper, that prevents any take of address when a field is accessed from payload, or payload itself.

On Monday, 11 April 2022 at 11:46:42 UTC, Alexandru Ermicioi wrote:
> On Sunday, 10 April 2022 at 23:12:03 UTC, rikki cattermole wrote:
>>
>> On 11/04/2022 3:04 AM, Alexandru Ermicioi wrote:
>>> Isn't better then to try and find design patterns or rules for use with mutable RC structures?
>>
>> Yes.
>>
>> But if the compiler allows RC to become const and not allow RC to occur, that is a bad situation to be in...
>
> This seems like a couple of edge cases and bugs that need to be rectified, in order to have proper safe mutable only RC structs. You should be able to disallow implicit cast to const of struct if it is desired to do so.

There's no issue here. You just write the copy constructor of RC!T to require a mutable source and destination object, and the compiler will refuse to copy a const(RC!T). (You can still pass by `const ref`, of course.)

> Regarding const rc use, I think there can be a limited access to the payload, if you somehow prohibit taking the address of the payload or it's sub-elements. Perhaps instead of returning payload itself from rc struct, maybe it can be wrapped into a wrapper, that prevents any take of address when a field is accessed from payload, or payload itself.

You can limit access by passing a `scope` reference to the payload to a callback function, as described in this comment:

https://github.com/dlang/phobos/pull/8368#issuecomment-1024917439

On Monday, 11 April 2022 at 14:44:18 UTC, Paul Backus wrote:
> There's no issue here. You just write the copy constructor of RC!T to require a mutable source and destination object, and the compiler will refuse to copy a const(RC!T). (You can still pass by `const ref`, of course.)

Obviously there are:
```d
import std;

void main()
{
    int j = 2;
    int k = 3;
    const r3 = Counted!int(&j);
    const(Counted!int) r4 = Counted!int(&k);
}

@safe struct Counted(T)
{
    private T* subject;
    private size_t* counter;

    this(T* subject)
    {
        this.counter = new size_t;
        this.subject = subject;
        *this.counter = 1;
    }

    this(ref T subject) const @disable;
    this(T* subject) const @disable;

    this(ref Counted!T counted)
    {
        this.subject = counted.subject;
        this.counter = counted.counter;
        ++(*this.counter);
    }

    this(ref Counted!(const T) counted) const @disable;
    this(ref const Counted!T counted) const @disable;
    this(ref Counted!T counted) const @disable;

    this(this) @disable;

    ~this()
    {
        (*this.counter)--;

        if ((*this.counter) == 0)
        {
            writeln("Freeing the subject: ", *this.subject);

            this.counter = null;
        }
    }

    // ~this() const @disable; Obviously another bug or uncharted area.

    void opAssign(ref Counted!T counted)
    {
        --(*this.counter);
        this.subject = counted.subject;
        this.counter = counted.counter;
        ++(*this.counter);
    }

    void opAssign(Counted!T counted)
    {
        this = counted;
    }

    void opAssign(ref const(Counted!T) counted) const @disable;
    void opAssign(const(Counted!T) counted) const @disable;
    void opAssign(Counted!(const T) counted) const @disable;
    void opAssign(ref Counted!(const T) counted) const @disable;
    void opAssign(ref Counted!T counted) const @disable;
    void opAssign(Counted!T counted) const @disable;

    void opCast(T)() @disable;
}
```

Or I missed something that will prevent these two use cases.

On Monday, 11 April 2022 at 16:40:42 UTC, Alexandru Ermicioi wrote:
> On Monday, 11 April 2022 at 14:44:18 UTC, Paul Backus wrote:
>> There's no issue here. You just write the copy constructor of RC!T to require a mutable source and destination object, and the compiler will refuse to copy a const(RC!T). (You can still pass by `const ref`, of course.)
>
> Obviously there are:
>
> [...]

I don't see what the problem here is. Two instances of `Counted!int` are created, and both are destroyed. No references are leaked or left dangling. If you try to copy-construct an additional instance, like

    auto r5 = r4;

...then the compiler correctly rejects the code.

Granted, it only works because the compiler-inserted destructor call ignores `const`, which is a little questionable, but I think in this case it's basically harmless.