April 08

On Friday, 8 April 2022 at 00:37:15 UTC, Zach Tollen wrote:

>

(With DIP1035, mutability is essential to what makes a given piece of data dangerous enough require being marked @system. And the whole point of __metadata is to force mutability bypassing the type system.)

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.

April 08

On Friday, 8 April 2022 at 01:24:38 UTC, Paul Backus wrote:

>

On Friday, 8 April 2022 at 00:37:15 UTC, Zach Tollen wrote:

>

(With DIP1035, mutability is essential to what makes a given piece of data dangerous enough require being marked @system. And the whole point of __metadata is to force mutability bypassing the type system.)

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?

April 08

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.

April 08
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.
April 08

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.

Best regards,
Alexandru.

April 08

On Friday, 8 April 2022 at 13:50:01 UTC, Alexandru Ermicioi wrote:

>

...

Text was misquoted, sorry.

April 08
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

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

On Friday, 8 April 2022 at 02:32:29 UTC, 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:
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.

It's only non-obvious if you define @system variables simply as "not usable from @safe code." If you defined them as "can also override the type system," it would be obvious.

The only question is whether this is a good language design. It is certainly easy to explain:

Q: "What are @system variables?"

A: "They are variables you can do anything you want with, as long as it's from @system code."

Q: "What are they for?"

A: "They're for doing things you can't do with regular variables, and also for marking regular variables as dangerous when the compiler can't figure that out on its own."

April 08

On Friday, 8 April 2022 at 08:23:34 UTC, Timon Gehr wrote:

>

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.

No it's not. Bad language design is when you arbitrarily conflate different things without first examining the pros and cons. But it's also bad language design not to be open to the possibility of a conflation of different things which ends up being harmonious and easy to explain.

April 08
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).