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

[Stanislav Blinov]

On Wednesday, 17 June 2020 at 21:20:00 UTC, mw wrote:
> On Wednesday, 17 June 2020 at 21:01:53 UTC, Ali Çehreli wrote:
>> On 6/17/20 1:38 PM, mw wrote:
>> (Aside: I think this thread should be on the 'learn' forum.)
>
> That's my initially thought, but then I realized this could be 
> a D bug, or a feature request.
>
>> struct refInt {...}
>
> Yes, I know there are work-around, but for my usage:
>
> https://github.com/mingwugmail/liblfdsd/blob/master/liblfds.dpp#L52
>
> all these work-around are too heavy, a verbatim typedef in my 
> question is the most succinct way to be used.
>
> Sigh, looks like it's not supported at this time, guess I have 
> to write more `static if`s.

This is not a bug, this is by design.

Also, you're trying to escape a pointer to arbitrary non-`shared` 
data residing on the stack into some global, shared, storage. 
I.e. (a) to not cause UB, you will need to make sure the consumer 
gets the data before you go out of scope, which defeats the 
purpose of this lock-free queue. And (b) to not cause UB, you 
will need to make sure consumer does not access the data 
concurrently with the producer.

With that taken into account, if you do want to be escaping 
pointers, just escape pointers.