What functions can be called on a shared struct that's implicitly castable to immutable?

deadalnix deadalnix at gmail.com
Mon Nov 4 00:46:03 PST 2013


On Monday, 4 November 2013 at 08:14:57 UTC, Simen Kjærås wrote:
>
> On 04.11.2013 06:53, deadalnix wrote:
>> On Sunday, 3 November 2013 at 21:55:22 UTC, Simen Kjærås wrote:
>>> Consider:
>>>
>>> module foo;
>>>
>>> struct S {
>>>    immutable(int)[] arr;
>>>    void fuzz() const pure {
>>>    }
>>> }
>>>
>>> void bar(S s) {
>>>    s.fuzz();
>>> }
>>>
>>> void main() {
>>>    shared S s;
>>>    bar(s);   // a
>>>    s.fuzz(); // b
>>> }
>>>
>>>
>>> In this case, the line marked 'a' works perfectly - it 
>>> compiles and does what I'd expect it to.
>>>
>>> However,the line marked 'b' does not compile - " non-shared 
>>> const method foo.S.fuzz is not callable using a shared 
>>> mutable object ".
>>>
>>
>> It is because a imply a pass b value, when b a pass by 
>> reference.
> Indeed. That's why I wrote that one line further down. That's 
> not the point. The point is I have to jump through no hoops to 
> get line a to compile - no 'assumeUnshared', no cast, no 
> explicit copying.
>
> On that basis, I argue that line b could be made to work by 
> silently creating a copy of s, because the call to fuzz is 
> guaranteed not to change s. There may be problems with this 
> that I have not considered. If you know of any, please do tell.
>
> I guess it might be conceivable that fuzz waits for a 
> synchronization message (but is that really possible in a pure 
> const function?), which will never happen for the copy, but is 
> this even a case we want to support?
>
> --
>   Simen

You are trying to solve a non problem here. s is not shared in 
the first place, so you can start by fixing it here.

Now, if S has some indirection, then it make sense to mark it as 
shared, but then the trick you propose won't work.


More information about the Digitalmars-d mailing list