RfC for language feature: rvalue struct

[H. S. Teoh]

On Tue, Jan 31, 2023 at 01:02:57PM +0000, FeepingCreature via Digitalmars-d wrote:
> On Tuesday, 31 January 2023 at 11:52:33 UTC, Dukc wrote:
> > On Tuesday, 31 January 2023 at 07:31:58 UTC, FeepingCreature wrote:
> > > On Monday, 30 January 2023 at 20:15:48 UTC, Dukc wrote:
> > > > I don't see a need for fields to be non-referenceable since
> > > > immutability protects them if the data in question is already
> > > > committed.
> > > 
> > > Yes, again, the idea is that rvalue allows *overwriting mutable
> > > variables* of this type.
> > 
> > In that case I'd probably go with a mutable pointer to an immutable
> > struct. That way you can replace the value in whole, but not single
> > fields of it.
> 
> Okay, now how do you do that without causing GC load? :) Keep in mind
> that we plan to use this for very inner loops of not-always-cheap
> algorithms.

Why would a mutable pointer to an immutable struct cause GC load? Isn't
it just a matter of taking an address?

	struct S { ... }
	S s, t;
	immutable(S)* ptr = &s;
	...
	ptr = &t;
	... // etc


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson