>> I guess we could use return-by-alias here, yes. I was kind of assuming >> everybody hated that and wanted it to go away. But if we use that we >> can no longer return a tag to indicate end of sequence (you can't >> currently wrap a reference in a data structure -- supporting that >> would get way too hairy). > > True, it's a bummer. At some point you just need to start using swap if you > want to avoid copies. Or you iterate by index only (probably the least > painful solution).
Your remarks about making option::t special do open up a possible road here. We could represent optional reference returns as 'return either a reference or a null pointer'. That's still pretty ugly, but it'd make for both a nice iterater protocol and a way to make std::map::lookup return a reference. I still consider using swap to return things an absolute non-solution. Try writing some code in that style. Unless I'm missing some part of the way you want to approach this, it's absolutely dreadful to work with. > This sort of thing is why I think @ is going to end up being pretty common > in real-world code. Not too bad IMHO; optimizing heap allocation is > well-studied, after all. Sure, but being a heap-centric language is completely opposed to what we've been doing so far. A language has shouldn't straddle the fence about the style it prefers, or you get a mess. We should either go modern-style (allocate everything except immediates, garbage-collect, use escape analysis to put some allocations on the stack), or C-style (stack is default, go out of our way to provide safe references). Doing both seems bad taste. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
