I was going to suggest something similar (the same thing?) -- it seems like putting the box's contents in a local variable is something that could be done automatically. Forcing the programmer to do it seems kind of noisy and not obvious about what purpose it's serving.
Dave On Jun 4, 2011, at 9:25 AM, Niko Matsakis wrote: > This message brings up at a point I wanted to ask: > > It seems that alias types could be handled in a relatively straight-forward > fashion using ref-counting, though this clearly entails some runtime cost. > It would also mean that things like alt(x) would "just work", as the > extracted value would be stored into a local variable which would up its ref. > count, so when x changes the subcomponent remains live. > > Are there other arguments against ref-counting besides the runtime cost? One > complication I can imagine is that in generic functions, the type of the > aliased value may not be precisely known, and ref-counting is not suitable > for some types (e.g., int), so something like tagged pointers, auto-boxing or > code specialization would be required. > > > Niko > > Marijn Haverbeke wrote: >> >>> Yes on (A); no on (B). You have to swap a value in of the appropriate type >>> (including constrained types), so there doesn't seem to be anything >>> inconsistent about it. In the case of hash tables, I was thinking we would >>> have a special "in_use" tag variant for this purpose. >> >> Well, yes, I guess that'd work. But we'd be punching holes in our >> table (which can cause further unpredictable run-time errors on nested >> access -- which is common) and writing a bunch of extra code just to >> avoid bumping up a refcount. I'm not sure there's going to be a real >> win here. >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
