On 09/11/2021 2:14 PM, tsbockman wrote:
> What you seem to be asking for instead is a way to trick the type system into agreeing that mutating a reference count doesn't actually mutate anything, which is nonsense. If that's really necessary for some reason, it needs to be special cased into the language spec, like how `pure` explicitly permits memory allocation.

Imagine saying to someone:

Yes you have made this struct immutable.

Yes you have set this bit of memory containing that immutable struct to read only.

Yes you ended up with a crashed program because that immutable struct went ahead and tried to write to that read only memory.

And yes, I understand that you couldn't have known that a field that you didn't write the implementation of used an escape hatch to write to const data.

It doesn't make sense.

On Tue, Nov 09, 2021 at 02:22:26PM +1300, rikki cattermole via Digitalmars-d wrote:
> 
> On 09/11/2021 2:14 PM, tsbockman wrote:
> > What you seem to be asking for instead is a way to trick the type system into agreeing that mutating a reference count doesn't actually mutate anything, which is nonsense. If that's really necessary for some reason, it needs to be special cased into the language spec, like how `pure` explicitly permits memory allocation.
> 
> Imagine saying to someone:
> 
> Yes you have made this struct immutable.
> 
> Yes you have set this bit of memory containing that immutable struct to read only.
> 
> Yes you ended up with a crashed program because that immutable struct went ahead and tried to write to that read only memory.
> 
> And yes, I understand that you couldn't have known that a field that you didn't write the implementation of used an escape hatch to write to const data.
> 
> It doesn't make sense.

Yes, subverting the type system with __mutable doesn't make sense. It just adds all kinds of loopholes and other unwanted interactions to the language.  A better approach is to have a nice way of converting const(Wrapper!T) -> Wrapper!(const T), so that we can implement a refcount in Wrapper without violating the type system.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

On Mon, Nov 08, 2021 at 10:38:59PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 11/8/21 8:04 PM, deadalnix wrote:
> > On Monday, 8 November 2021 at 22:40:03 UTC, Andrei Alexandrescu wrote:
> > > On 2021-11-08 17:26, rikki cattermole wrote:
> > > > a reference counted struct should never be const
> > > 
> > > So then we're toast. If that's the case we're looking at the most important challenge to the D language right now.
> > 
> > Not necessarily, but this is in fact the same problem as the head mutable problem.
> > 
> > If `const RCSlice!(const T)` can convert to `RCSlice!(const T)`,
> > which it should to have the same semantic as slice.
> > 
> > The reference counting problem goes away if you can mutate the head.
> 
> The reference count cannot be in the head, it has to be in the block. So this conversion is actually unsound.
[...]

It could work if the block has a mutable counter at the top and the rest is immutable/const.  But the current type system cannot express such a thing; if the head is const, then it's const all the way down.


T

-- 
Two wrongs don't make a right; but three rights do make a left...

On Monday, 8 November 2021 at 22:07:46 UTC, Adam Ruppe wrote:
> On Monday, 8 November 2021 at 21:42:12 UTC, Andrei Alexandrescu wrote:
>> - work with qualifiers like T[] does, both RCSlice!(qual T) and qual(RCSlice!T)
>
> I think this is an incorrect requirement. A const(T) is now allowed to increase a reference count by definition.

This is technically true, but he wrote "built in", so then you don't have to heed the same constraints. You only have to require that acquire()/release() match up, so how that is accounted for is an implementation detail since you don't provide any access to the count.

Same goes for pure functions. You can imagine that all pure function calls have a hidden parameter with "ref count storage", which it is allowed to modify.

So you might be able do this without breaking the type system, if it is builtin, but you have to prove it.

(Basic implementation is to use fat pointers and keep the counter in mutable memory, like shared_ptr. Anything beyond that is an optimization.)

On Tuesday, 9 November 2021 at 09:02:32 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 8 November 2021 at 22:07:46 UTC, Adam Ruppe wrote:
>> On Monday, 8 November 2021 at 21:42:12 UTC, Andrei Alexandrescu wrote:
>>> - work with qualifiers like T[] does, both RCSlice!(qual T) and qual(RCSlice!T)
>>
>> I think this is an incorrect requirement. A const(T) is now allowed to increase a reference count by definition.
>
> This is technically true, but he wrote "built in", so then you don't have to heed the same constraints. You only have to require that acquire()/release() match up, so how that is accounted for is an implementation detail since you don't provide any access to the count.
>

Yes. In addition, it is worth mentioning that many functional programming languages are using reference counting internally. It is so that they can do copy on write instead of copying everything all the time for no reason.