The "no gc" crowd

[Sean Kelly]

On Oct 10, 2013, at 11:17 AM, Joseph Rushton Wakeling <joseph.wakeling at webdrake.net> wrote:

> On 10/10/13 19:50, Sean Kelly wrote:
>> Configuration data, for example.  On app start you might load a config file, generate information about the user, and so on, before real processing begins.  This data needs to be visible everywhere and it rarely if ever changes as the program runs, so you fill the data structures and then make them immutable.  Assuming, of course, that the data structures have immutable versions of all the necessary functions (which is unfortunately a pretty big assumption).
> 
> Yup, you're right, it's a big assumption.  In my case I was interested in loading a graph (network) and running many simulations on it in parallel.  The graph itself was static, so could readily be made immutable.  However, I found that it was difficult to write code that would accept both immutable and mutable graphs as input, without impacting performance.  So, I opted for threads to receive an immutable graph and cast it to mutable, even though it was never actually altered.
> 
> My experience was no doubt partially due to issues with the overall design I chose, and maybe I could have found a way around it, but it just seemed easier to use this flawed approach than to re-work everything.

That's kind of the issue I ran into with shared in Druntime.  It seemed like what I had to do was have a shared method that internally cast "this" to unshared and then called the real function, which I knew was safe but the type system hated.  But this seemed like a horrible approach and so I didn't ever qualify anything as shared.