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
