refInt = ref int: how to achieve this? or is this a bug?

[Stanislav Blinov]

On Thursday, 18 June 2020 at 01:21:52 UTC, mw wrote:

> Thank you for your comments.
>
> But I think you complicated the design: C is C, D is D. So let
>
> -- C manage C's memory (the container), and
> -- D manage D's memory (the objects)
>
> The only thing interfacing is simple the (void*) as *value*.
>
> -- all primitive types | class (pointers)'s *value* are stored 
> as value of (void*)
> -- all (fat) objects' *address* are stored as value of (void*)
>
> The only extra requirement on the D side is to keep reference 
> to those fat objects to avoid it being GC-ed before being 
> pop-ed.
>
> (Just as don't push a stack var into any-type-of queue, and pop 
> it after the stack is gone -- this are the responsibility of 
> the programmer, not the container.)
>
> That's all.

So... not doing this:

queue.push(new Object); // receiver may get garbage reference

or this (when compiled with -preview=rvaluerefparam, in other 
words, when rvalues would be allowed to bind to refs):

queue.push(FatStruct()); // temporary is gone after push() returns

or, more to the point, since you want this to be very "generic":

queue.push(createStuff!options()); // yeah, createStuff is 
somewhere inside 20kLOC in another module

...NOT doing any of those are all also programmer's 
responsibility?

You're absolutely correct, C is C, and D is D, and type system 
exists for a reason, yet you're trying to circumvent it, and 
don't like it when the language fights back.

Like I originally remarked, if you *want* to be escaping 
pointers, then escape pointers, and state as much in your 
interface. That will simplify it (the interface), and leave your 
users (i.e. "the programmers") with no illusions as to what's 
going on.

...or, realize that values and references have different 
semantics, and require different handling (in other words, 
different queue types).