alias SyncData = immutable(JSONValue);

void worker(string filename) {
  SyncData data = filename.readText.parseJSON;
  send(ownerTid, data);
}

void main(string[] args) {
  spawn(&worker, args[1]);
  writeln(receiveOnly!SyncData);
}

I'm trying to send this immutable(JSONValue) back to the main thread but when trying to compile, I get the following error:

> /usr/include/dmd/phobos/std/concurrency.d(764): Error: cannot modify immutable expression ret.__expand_field_0
> cc.d(15): Error: template instance `std.concurrency.receiveOnly!(immutable(JSONValue))` error instantiating

Can anyone help out?

On 1/10/19 12:15 PM, rx wrote:
> alias SyncData = immutable(JSONValue);
> 
> void worker(string filename) {
>    SyncData data = filename.readText.parseJSON;
>    send(ownerTid, data);
> }
> 
> void main(string[] args) {
>    spawn(&worker, args[1]);
>    writeln(receiveOnly!SyncData);
> }
> 
> I'm trying to send this immutable(JSONValue) back to the main thread but when trying to compile, I get the following error:
> 
>> /usr/include/dmd/phobos/std/concurrency.d(764): Error: cannot modify immutable expression ret.__expand_field_0
>> cc.d(15): Error: template instance `std.concurrency.receiveOnly!(immutable(JSONValue))` error instantiating
> 
> Can anyone help out?

Looks like a long-standing bug (there are several related issues about sending/receiving immutable data). The way std.concurrency.receiveOnly works is it creates a temporary result, then puts the received item into the result, and then returns it. But you can't copy an immutable into a temporary that's already immutable.

e.g. it looks like this:

immutable int x;
x = 5; // error

I don't know if there's a specific "can't receive immutable data" issue report, but certainly, you can add your issue to the list.

-Steve

On 1/10/19 1:20 PM, Steven Schveighoffer wrote:

> I don't know if there's a specific "can't receive immutable data" issue report, but certainly, you can add your issue to the list.

Actually, this one is nearly identical and quite new, you can just add to that one:

https://issues.dlang.org/show_bug.cgi?id=19345

-Steve

On Thursday, 10 January 2019 at 18:25:44 UTC, Steven Schveighoffer wrote:
> On 1/10/19 1:20 PM, Steven Schveighoffer wrote:
>
>> I don't know if there's a specific "can't receive immutable data" issue report, but certainly, you can add your issue to the list.
>
> Actually, this one is nearly identical and quite new, you can just add to that one:
>
> https://issues.dlang.org/show_bug.cgi?id=19345
>
> -Steve

Thanks Steve. I suppose when the documentation talks about preferring message passing immutable data it means just use plain old receive. I can just use a template I anyway.

Would you estimate this Phobos bug to be particularly hard to solve?

On 1/10/19 2:36 PM, rx wrote:
> On Thursday, 10 January 2019 at 18:25:44 UTC, Steven Schveighoffer wrote:
>> On 1/10/19 1:20 PM, Steven Schveighoffer wrote:
>>
>>> I don't know if there's a specific "can't receive immutable data" issue report, but certainly, you can add your issue to the list.
>>
>> Actually, this one is nearly identical and quite new, you can just add to that one:
>>
>> https://issues.dlang.org/show_bug.cgi?id=19345
>>
> 
> Thanks Steve. I suppose when the documentation talks about preferring message passing immutable data it means just use plain old receive. I can just use a template I anyway.
> 
> Would you estimate this Phobos bug to be particularly hard to solve?

Not sure. It would involve casting away immutable, which has to be done carefully. Probably nobody has had motivation enough to fix it yet.

-Steve

On Thursday, 10 January 2019 at 20:21:04 UTC, Steven Schveighoffer wrote:
>> Thanks Steve. I suppose when the documentation talks about preferring message passing immutable data it means just use plain old receive. I can just use a template I anyway.
>> 
>> Would you estimate this Phobos bug to be particularly hard to solve?
>
> Not sure. It would involve casting away immutable, which has to be done carefully. Probably nobody has had motivation enough to fix it yet.
>
> -Steve

I might take a look at it but obviously I don’t want to screw it up if it’s complex.