> 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
