> Yeah. To an extent. You also have a & let-binding that is connected -- via
> rules that I feel are getting well-beyond obvious -- to the underlying
> hashtable.
The let& binding is orthogonal to return-by-reference. You can see a
return-by-reference accessor as behaving analogous to dot operator
field access -- you get a reference to the contents of the thing
you're accessing. You can then, if you're not particularly concerned
about efficiency, simply copy that into a local. Or you can directly
access it or pass it to a function, in which case nothing complicated
happens either. When you want to refer to it multiple times, you have
the choice of storing it in a by-reference local variable (the
compiler will tell you when that's not safe), or simply calling the
accessor multiple times (which, for simple accessors, can be easier).
Now, consider the access-by-block solution. We're only using this for
str::as_buf* right now, but it's already jumping out as an eyesore:
let llfn: ValueRef =
str::as_buf(name, {|buf| llvm::LLVMAddFunction(llmod, buf, llty) });
Compare
let x = option::get(option::get(optopt));
let x = option::get(optopt, {|opt| option::get(opt, {|x| x})});
We can put some syntactic sugar on that, but the fact remains that
more concepts are being thrown around (and the generated code will be
more complex). Having those blocks in the code is, for programmers who
are anything like me, a major turn off. You'll often have to provide
two forms of an accessor, a simple one which returns the value, and an
efficient one which works by block. In the by-reference approach, a
single accessor serves both roles.
* About str::as_buf -- the return-value-depends-on-an-argument
notation could be extended to also cover this case... though I'm not
sure such functions (unsafely accessing value contents) are common
enough to merit that.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
