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.