On 08.04.22 04:32, Paul Backus wrote:
> On Friday, 8 April 2022 at 01:46:35 UTC, Zach Tollen wrote:
>> On Friday, 8 April 2022 at 01:24:38 UTC, Paul Backus wrote:
>>> This is not entirely true. DIP 1035 also specifies that variables whose initial values would not be allowed in `@safe` code are inferred as `@system`, and this applies equally to mutable and `immutable` variables.
>>
>> So it's dangerous enough to be pointing to undefined memory, but it still needs the protection of immutable because... some `@system` programmer might want it to point to something else... and we can't allow that to happen, because `@system` programmers shouldn't be allow to do something like that?
>>
>> In other words, if it's dangerous enough to start out as `@system`, how much additional danger are we adding by making it mutable?
> 
> You're not adding any additional *danger*, I suppose, but it would be a non-obvious special case in the type system to have the `@system` attribute on variables interact with `immutable` like this. As currently proposed by DIP 1035, they are completely independent of each other.

Yes. I do not understand why so many people are so keen to conflate entirely different things into the same concepts. That's just bad language design.

On Fri, Apr 08, 2022 at 01:50:01PM +0000, Alexandru Ermicioi via Digitalmars-d wrote:
> On Wednesday, 6 April 2022 at 09:41:52 UTC, RazvanN wrote:
> > ...
> It may be a dumb and already discussed question, but what's the problem of making rc counted structs mutable only?
> 
> In this way, you won't have the dilemma of circumventing the immutable/const system, to just increment the counter, or any metadata.
> 
> Note: the payload of rc struct, may be const or immutable if needed.
[...]

In theory, this would IMO be the right approach.  However, it does hamper usability. For example, you could no longer write:

	auto myFunc(in RC!Data data) { ... }

but you'd have to write instead:

	auto myFunc(RC!(const(Data)) data) { ... }

because RC!... has to remain always mutable.

Some of the nice implicit conversions would also no longer work as
desired, e.g., RC!Data would not implicitly convert to RC!(const(Data)),
where with GC'd data, Data* implicit converts to const(Data)*. This
asymmetry makes metaprogramming harder to work with RC.

Things get worse once you have nested structures, e.g.:

	struct SubData {...}
	struct S {
		RC!SubData data;
	}

Now you couldn't pass S to anything that takes const, because transitivity of const would force RC!SubData to be const(RC!SubData), which breaks the refcounting mechanism.  Basically, once you have RC!xxx in any subpart of your data structure, it "reverse-infects" the entire data structure with mutable, because you can no longer use const on any containing part of the structure, since it would break RC.

Basically, unless you have a hack like __mutable, you basically have to throw out const/immutable entirely from your data structures once any part of it involves RC.


T

-- 
Век живи - век учись. А дураком помрёшь.

On Friday, 8 April 2022 at 14:23:01 UTC, H. S. Teoh wrote:
> Basically, unless you have a hack like __mutable, you basically have to throw out const/immutable entirely from your data structures once any part of it involves RC.

You can make RC work with const and immutable if you're willing to give up on pure:

https://gist.github.com/pbackus/1638523a5b6ea3ce2c0a73358cff4dc6

Personally, I would rather give up on pure (which already has loopholes in it) than add a loophole to immutable (which currently has none).