--- Comment #10 from Don <> 2009-10-05 07:11:21 PDT ---
(In reply to comment #7)
> For me this compiles:
> ----
> __gshared char[] str;
> char fun(in char[] s) pure
> {
>     return s[0];
> }
> int main()
> {
>     char a=fun(str);
>     return 0;
> }
> ----
> __gshared is not a type modifier.

Ouch. That definitely shouldn't compile. Obviously 'pure' isn't doing any
parameter checking at all. The parameter isn't even const!!

But yes, I agree there's a problem there. It's not going to work if __gshared
parameters are passed to pure functions. Note that __gshared isn't allowed in
SafeD, but still, this is starting to look ugly.

> Sharing feature is young, it's still not clear how well it suits real code,
> recently its behavior has changed to imply synchronization, we don't know
> whether it will be widely adopted, so I don't think It's a good idea to rely 
> on it so hardly.

Yes. Although the only long as 'shared' remains transitive, it'd be OK.

(In reply to comment #9)
> > Note that you can just look at the parameter list and distinguish levels of
> > purity: if there are any non-immutable reference parameters, it's not 
> > cachable.
> > I guess the question is whether that additional complexity is justified.
> Yes, two flavors of pureness can be introduces, it should be documented, what
> optimizations can be applied to them in relation to threading model. But isn't
> it a lot of work to specify and implement two flavors of pureness at the same
> time?
No, because you can get it trivially from the function signature. The big
problem is that from the user's point of view, the language is too complicated
already. Although, this really only affects optimisation, so users don't really
need to know about it.

 At this time optimization for non-immutable arguments should be turned
> off until it's implemented correctly. Does dmd perform any pure optimizations
> at this time?

Almost none.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to