Once stack functions have nothing to do with RAII. It is about container manipulation methods. Consider the mangle function of a hashmap for example. It makes perfect sense to be able to access a borrowed pointer and also consume an owned pointer inside the mangle actions. This is currently impossible "just because".
I have ~10K of Rust LOC in my pet project and I run into this problem more than a dozen times. I ended up using cells and other nastiness to work around what is essentially an artificial restriction. Passing actions to other tasks is all well and good, and repeatedly applying a function to many container members (e.g., "mapping" or "folding") is also common. Both of these use cases are very well supported. But it is as common to have a container that invokes a function exactly once on one specific member (as another example, basically any function of the Option type that invokes an action). And this common use case is very badly supported. On Sat, Nov 30, 2013 at 10:23 AM, Patrick Walton <[email protected]>wrote: > I don't want stack once functions, because I feel that their use cases are > better served with RAII, which serves the same purposes without rightward > drift and without forcing LLVM to perform devirtualization. > > Patrick > > Oren Ben-Kiki <[email protected]> wrote: >> >> I find `do` syntax form is vital for DSL-ish code. Getting rid of it >> makes a lot of code look downright ugly. I'd rather it used a more Ruby-ish >> notation though, I find that putting the `do` far away from the `{ ... }` >> doesn't read well. `foo(....) do |...| { ... }` would have made more sense >> for me (think of `do` as a macro-ish binary operation injecting the proc >> into the function on the left). But the current form is acceptable. >> >> Syntax niceties aside, I find it extremely problematic that we have only >> two forms of "callable", one that is on the stack but can be called >> multiple times, and one that is on the heap and can only be called once. >> This arrangement sort-of-makes-sense when one thinks from an implementation >> point of view, but I find it to lack a crucial use case, that of a form >> that is on the stack and is also called only once. >> >> The reason this 3rd form is so important is the extremely common case of >> a container that wants to take an action as a parameter for a method. >> >> ``` >> ... some_non_sendable_variable ... >> ... some_owned_variable ... >> do container.do_something_at_most_once |...| { ... use *both* variables >> ... } >> ``` >> >> This is a lose-lose situation. If the container takes a `proc`, then Rust >> complains that it can't capture the non-send-able variable. But if the >> container takes a stack closure, then Rust complains it can't use the owned >> variable. Of course, the container will _not_ send the action and will also >> _not_ call it twice, but it can't express this in the action type :-) The >> only workaround I found is to use a closure and wrap each and every >> non-send-able variable in a cell - this is an pointless and downright >> annoying manual boilerplate code. >> >> As long as this area of the language is being changed, I think that >> adding this missing 3rd variant should definitely be discussed (and >> hopefully implemented). This would affect the syntax discussion because >> there would be three forms instead of two; there are some more and less >> obvious choices here but they are secondary to the core issue of allowing >> the 3rd variant in the 1st place. >> >> On Sat, Nov 30, 2013 at 9:02 AM, Chris Morgan <[email protected]>wrote: >> >>> (a) Kill ``do`` >>> >> ... >> >>> (b) Make ``do`` support both closures and procedures >>> >> ... >> >> ------------------------------ >> >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
