On 17/09/2011 2:49 PM, Marijn Haverbeke wrote:
So here we have an&, or a&1, in the accessor definition (once),
versus wrapping your computation in a block, on every single use of
the accessor.
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 user has little clue in their code why the
hashtable is connected to the value they got out. They can guess, or go
look at the signature ... it feels like it'll surprise.
Let's leave my code in for now, and play with both approaches. I am
quite confident that access-by-reference will prove to be more
pleasant.
Ok.
They seem to work well in languages that use them, no?
I've never used a language that does this. Examples?
I suppose I'm thinking of those languages that use blocks primarily for
iteration rather than single-element access: functional and OO languages
(MLs, lisps, smalltalks, etc.) that use the pass-a-closure-down style of
iteration.
I'm extending -- perhaps unfairly -- the idea in that feature to
single-element accessors on the grounds that few languages have *any*
strategy handle safe reference-to-interior-allocation lifetimes other
than "allocate everything in the heap and gc when you can". Which
obviously feels even worse to me. We're already desugaring the for-loop
form as another way of composing a block and passing it in (I think!);
would you consider a block form of let?
let v = accessor(x) in {
...
}
as an alternative sugar for:
accessor(x, {|v| ... });
I'm sorry to have sounded dismissive; am certainly not vetoing the
concept, was just providing an initial gut feeling of "it feels kinda
wrong or overcomplex". I'm ok with "leave it in and play with both, see
which works best", as you say. Or tinker with the syntax and rules some.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
