On 01/29/2014 11:44 AM, Niko Matsakis wrote:
On Tue, Jan 28, 2014 at 07:01:44PM -0500, comex wrote:
Actually, Rust already has procedural macros as of recently. I was
wondering whether that could be combined with the proposed new system.
I haven't looked in detail at the procedural macro
Considering the effort to break up libextra into multiple crates in
#8784[1], could rust-crypto[2] be moved back into rust as libcrypto?
Some comments on the issue deviated about whether crypto should written
*in* Rust, or just be bindings. As a user, I don't care how they are
implemented, as
On Wed, Jan 29, 2014 at 1:12 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't think it's possible to make a nice NSS binding because it
depends on thread-local initialization.
:(
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
After reading about the simultaneous stream reading/writing issue discussed
in the last meeting, I want to ask a question: Maybe it's time to consider
using explicitly async I/O and futures?
Futures sort of already exist in the libextra, but they still rely on
pushing async operation into a
On Wed, Jan 29, 2014 at 5:03 PM, Vadim vadi...@gmail.com wrote:
But maybe Rust type system could grow a new type of borrow that prevents all
object access while it is in scope, similarly to how iterators prevent
mutation of the container being iterated?
Vadim
An `mut` borrow will prevent
What event initiates the write?
On Wed, Jan 29, 2014 at 2:11 PM, Kevin Ballard ke...@sb.org wrote:
This solution will not work for what I need stream splitting for. Namely,
I need to be in the middle of reading from a socket when I decide that I
need to write. I cannot be waiting on the read
Any number of things.
The use case here is an interactive protocol where writes go in both
directions, and can be initiated in response to external events. The classic
example is an IRC bot. The server can send a message at any time, so the IRC
bot needs to be constantly reading, but writes
On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard ke...@sb.org wrote:
Any number of things.
The use case here is an interactive protocol where writes go in both
directions, and can be initiated in response to external events. The
classic example is an IRC bot. The server can send a message at
On Jan 29, 2014, at 4:16 PM, Vadim vadi...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard ke...@sb.org wrote:
Any number of things.
The use case here is an interactive protocol where writes go in both
directions, and can be initiated in response to external events.
Sure, we can call it a generalization of select.
But, (assuming you mean posix select()) they wouldn't be limited to fd's,
could be more granular (not just ready for read/write/error), and they
compose better.
Also, if we could find a way to rope off the buffers, I/O would place data
directly
On 1/29/14 6:34 PM, Samuel Williams wrote:
Perhaps this has been considered already, but when I'm reading rust code
let mut just seems to stick out all over the place. Why not add a
var keyword that does the same thing? I think there are lots of good
and bad reasons to do this or not do it, but
On 01/29/2014 06:35 PM, Patrick Walton wrote:
On 1/29/14 6:34 PM, Samuel Williams wrote:
Perhaps this has been considered already, but when I'm reading rust code
let mut just seems to stick out all over the place. Why not add a
var keyword that does the same thing? I think there are lots of
On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com wrote:
On 01/29/2014 06:35 PM, Patrick Walton wrote:
On 1/29/14 6:34 PM, Samuel Williams wrote:
Perhaps this has been considered already, but when I'm reading rust code
let mut just seems to stick out all over the place. Why
Part of the nice thing about `let mut` is that it requires you to opt-in to
mutability, making it a conscious choice.
Having `let` and `var` would make Rust be like ES6: we all look at `let`
and say why bother. For Rust, I imagine many would get into the habit of
using `var` over `let` because
let mut is to some degree syntactic salt, in my mind. Minimizing
mutability as the easy thing to do creates better code, I think. That
isn't to say mutability is a bad thing, but more that you should think
about whether you need it when you're writing code.
I'm not convinced the incremental
I guess the main gain would be less typing of what seems to be a reasonably
common sequence, and the formalisation of a particular semantic pattern
which makes it easier to recognise the code when you visually scanning it.
On 30 January 2014 15:50, Kevin Ballard ke...@sb.org wrote:
On Jan 29,
On Wed, Jan 29, 2014 at 9:52 PM, Sean McArthur smcart...@mozilla.com wrote:
Part of the nice thing about `let mut` is that it requires you to opt-in to
mutability, making it a conscious choice.
Having `let` and `var` would make Rust be like ES6: we all look at `let` and
say why bother. For
Last I did a survey, `let mut` was less than half (and more around
30-40%) of the `lets` I found, though it wasn't exhaustive. It's also
important to note that Rust is not a language suited for new
programmers. Far too many concerns; it tackles hard problems and makes
tradeoffs that new
On 30/01/14 14:09, Samuel Williams wrote:
I agree that it is syntactic salt and that the design is to discourage
mutability. I actually appreciate that point as a programmer.
w.r.t. this specific issue: I think what concerns me is that it is
quite a high burden for new programmers (I teach
Do you think for client code it would be the same proportion as in
library code?
On 30 January 2014 16:13, Huon Wilson dbau...@gmail.com wrote:
On 30/01/14 14:09, Samuel Williams wrote:
I agree that it is syntactic salt and that the design is to discourage
mutability. I actually appreciate
What about constant folding? Surely let mut x = 10 is easier for the
compiler to optimise?
On 30 January 2014 16:18, Daniel Micay danielmi...@gmail.com wrote:
On Wed, Jan 29, 2014 at 10:09 PM, Samuel Williams
space.ship.travel...@gmail.com wrote:
I agree that it is syntactic salt and that
On 1/29/14 7:20 PM, Samuel Williams wrote:
What about constant folding? Surely let mut x = 10 is easier for the
compiler to optimise?
In less advanced compilers, that may be true. But Rust internally
converts everything to SSA, so there is no difference.
Patrick
On Wed, Jan 29, 2014 at 10:20 PM, Samuel Williams
space.ship.travel...@gmail.com wrote:
What about constant folding? Surely let mut x = 10 is easier for the
compiler to optimise?
Rust can warn with 100% accuracy if a variable is unnecessarily
mutable. So, there's no benefit in terms of
Running the same commands just inside src/librustc (which is essentially
client code) gives:
let mut = 1051
let (no mut) = 5752
So the ratio is even more skewed toward immutable lets, and, librustc is
written in old Rust, so I can only see the ratio moving away from let
mut even more: e.g.
'let mut' signals a let binding to a mutable variable...?
On Wed, Jan 29, 2014 at 10:26 PM, Samuel Williams
space.ship.travel...@gmail.com wrote:
Interesting - so if there is no difference, what is the point of let mut
?
On 30 January 2014 16:21, Patrick Walton pcwal...@mozilla.com wrote:
You *should* get sick of writing 'let mut' all over the place, not just b/c
of the syntax but b/c you're using mutable variables all over the place.
Casual mutability kills maintainability.
Affordances matter. I'm convinced that the reason Option.unwrap() is used
so frequently is b/c it's the
Jason, I haven't actually written any rust code (yet). I'm just commenting
based on reading other people's code - it was something I noticed in a few
examples - it might have been bad form (assuming that mutable data are the
Wrong Thing?). I brought it up because I wasn't sure if it was something
Sorry to parachute in to the conversation (long time lurker) but just to
add to the statistics, the Scala standard library and compiler has
11875:54575 ratio of mutable (var) vs immutable (val) declarations, so it
seems to match pretty well with the numbers you guys are seeing in the rust
I like the fact that is more expensive to write let mut than let. So you
initialize mutable variable on purpose
Le 30 janv. 2014 05:31, Haoyi Li haoyi...@gmail.com a écrit :
Sorry to parachute in to the conversation (long time lurker) but just to
add to the statistics, the Scala standard
Hi list,
I’d like the fact “a = 10” or “mut a = 10” are shorter to write than “let a =
10” or “let mut a = 10”.
On the other hand, I *really* appreciate the fact `grep -ri let src/ | grep (or
-v) mut` will return me quickly where the variable declaration are.
So in the end, I feel I can
30 matches
Mail list logo
