Hi Alex, thanks for the quick response! > Feel free to open a bug on the > issue tracker (https://github.com/rust-lang/rfcs/issues) or even open > an RFC on it! Due to it being a language change, you should register > the issue in the RFC repo instead of the rust repo.
Oh my, I'm allowed to start an RFC? I don't feel confident in providing the background you just mentioned, and I certainly don't have the expertise to implement it myself. But I can certainly give my rationale for why it would be a good idea (as I did in my email). Is that sufficient? > Technically speaking, this is "superior" to calling a function like > Foo::new, similar to how "placement new" works in C++. With the `box` > syntax, you're able to allocate a slot *before* the expression is > evaluated, which means the expression can be evaluated directly into > the destination. Ah, indeed! That makes a lot of sense. > Your example should in > theory (doesn't work today) be written as: > > let a: Box<int> = box 45i; > let b: Rc<int> = box(RC) 54i; Is there a fuller description of the intended syntax and how it works? A quick google for "rust box operator rfc" turned this up: https://github.com/rust-lang/rfcs/pull/59 But that discussion was only slightly informative regarding the intended syntax and semantics, and didn't seem to lead anywhere else that was more informative (though I may have missed it). > This is indeed odd! Currently the syntax you want is provided by > implementing the IndexMut trait, but it is blocked on > https://github.com/rust-lang/rust/issues/12825 before implementing it > for vectors. Be sure to follow the issue to watch the progress on it! Awesome! :-) > We've avoided the syntax you described due to the `fn()` type. This is > a raw function pointer which doesn't correspond to any environment. A > closure, however, is represented differently (it's not just one word) > and it also has an environment. We wanted to avoid the confusion by > making the function pointer type and closure syntax too similar, so we > opted to not use the `fn` keyword to declare a closure, but instead > use bars. Does that make sense? Yeah, that definitely makes sense. Thanks for the explanation! > This kind of feedback is definitely helpful! You may also be > interested in our subreddit [1] and our discuss forum [2]. Thank you > for your kind thoughts and opinions, and I hope I was able to answer > some of your questions! > > [1]: http://reddit.com/r/rust > [2]: http://discuss.rust-lang.org/ Awesome! I'll keep it coming then (although it's likely to be a trickle rather than a firehose). Is this an appropriate place to post such feedback, or would the subreddit and/or discuss forum be better? Also, I really appreciate you taking the time to respond to my email so thoroughly. --Nathan On Wed, Oct 8, 2014 at 1:56 PM, Alex Crichton <[email protected]> wrote: >> Disclaimer: please take all of this with a huge grain of salt. This >> feedback is meant with the humility of someone who surely doesn't >> fully understand the language yet and hasn't invested enough time into >> yet to be taken seriously. Much of what I say may have little bearing >> on anything. This is purely just to give my "fresh new user" >> perspective, in the hopes that it might be helpful somehow. > > Thanks so much for taking the time to write this up, this is well > written and I know we all definitely appreciate it! > >> It took me a stupidly long time to figure out that the 'mod' statement had >> to go after the 'use' >> statement. > > I believe there's actually an interesting historical precedent to > this! Awhile back we allowed names to shadow each other through > imports/declaration, and due to bugs in resolve the order of shadowing > was "extern crate", then "use statements", then "everything else". For > example, a program like this wouldn't work as expected: > > mod foo; > use bar::foo; > fn main() { foo(); } > > In that example, the call to `foo()` from `main` would actually > resolve to calling a module, which is illegal. > > Note, however, that we now disallow shadowing, so I believe that it's > plausible to lift this restriction. Feel free to open a bug on the > issue tracker (https://github.com/rust-lang/rfcs/issues) or even open > an RFC on it! Due to it being a language change, you should register > the issue in the RFC repo instead of the rust repo. > >> It feels awkward to me that Box and Rc have different ways of initializing: > > We are of similar minds! A little-known fact about `box` right now is > that its syntax is intended to be extensible. Your example should in > theory (doesn't work today) be written as: > > let a: Box<int> = box 45i; > let b: Rc<int> = box(RC) 54i; > > And furthermore, you can extend it even further: > > let c: Box<int> = box(HEAP) 1i; > let d: MyPointer<int> = box(MY_HEAP) 5i; > > Technically speaking, this is "superior" to calling a function like > Foo::new, similar to how "placement new" works in C++. With the `box` > syntax, you're able to allocate a slot *before* the expression is > evaluated, which means the expression can be evaluated directly into > the destination. Today, with a function like Rc::new, you evaluate the > expression beforehand onto the stack, and then you later copy the > value onto the heap (sub-par). > > This is technically feasible to implement today, and I believe that we > plan on implementing this before 1.0 and possibly deprecating > constructors like Rc::new and Arc::new. > >> # Can't Write to mut Vec # > > This is indeed odd! Currently the syntax you want is provided by > implementing the IndexMut trait, but it is blocked on > https://github.com/rust-lang/rust/issues/12825 before implementing it > for vectors. Be sure to follow the issue to watch the progress on it! > >> The syntax for lambdas/closures feels weird to me. Currently there >> are two syntaxes (||{} and proc(){}) which have different semantics. >> >> My understanding is that these are already going to be unified into >> one syntax, and that addresses most of my feeling of weirdness with >> them. But I also wonder if it would be possible to unify them even >> further with regular functions. > > This is certainly a nuanced topic! There's two different dimensions to > consider about closures: > > 1. Invokability, this corresponds to Fn/FnOnce/FnMut. This dictates > how many times a closure can be called, and how it borrows its called > (mutable reference or shared) > 2. Capturing outer variables. Variables can be captured by value or by > reference. > > The current plan of attack is to have two syntaxes for closures (still > under development: > > // infer invokability, infer how variables are captured > |a, b, c| foo + a + b + c > > // infer invokability, all variables are captured by value > move |a, b, c| foo + a + b + c > > The idea here is to remove the slightly odd 'proc' syntax, and bring > the two in line. The `move` keyword indicates that all captured > variables will be moved into the closure. > > We've avoided the syntax you described due to the `fn()` type. This is > a raw function pointer which doesn't correspond to any environment. A > closure, however, is represented differently (it's not just one word) > and it also has an environment. We wanted to avoid the confusion by > making the function pointer type and closure syntax too similar, so we > opted to not use the `fn` keyword to declare a closure, but instead > use bars. Does that make sense? > >> There is still a lot of Rust I haven't touched yet. I haven't played >> much at all with unsafe blocks, raw pointers, or named lifetimes among >> other things. As I dive further into Rust, would continued feedback >> like this be appreciated? Is this kind of feedback helpful? > > This kind of feedback is definitely helpful! You may also be > interested in our subreddit [1] and our discuss forum [2]. Thank you > for your kind thoughts and opinions, and I hope I was able to answer > some of your questions! > > [1]: http://reddit.com/r/rust > [2]: http://discuss.rust-lang.org/ _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
