Hi list.
2014-06-05 17:20 GMT+09:00 Chris Morgan m...@chrismorgan.info:
On Thu, Jun 5, 2014 at 9:01 AM, Brian Anderson bander...@mozilla.com
wrote:
# Date/Time (https://github.com/mozilla/rust/issues/14657)
Our time crate is very minimal, and the API looks dated. This is a hard
Hi,
Another aspect that can be considered is Dependent Types.
S
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 05/06/14 02:27 AM, Paul Nathan wrote:
This won't work in a CSP system. So
Rust isn't a pure CSP system. It has both immutable and mutable shared
memory alongside various forms of channels. The best tool for the job
will vary based on the specific use case. Channels will often be the
On 05/06/14 19:11, kimhyunk...@gmail.com wrote:
I was also planning to add sql!() macro almost exactly same as Chris
Morgan suggests. However, you can't directly access type-checking part
of rustc in #![phase(syntax)] modules, which means you need some dirty
hacks to peroperly type-check
# SQL (https://github.com/mozilla/rust/issues/14658) Generic SQL
bindings. I'm told SqlAlchemy core is a good system to learn
from.
What about basing it off Anorm?
http://www.playframework.com/documentation/2.3.x/ScalaAnorm
It's not an ORM so it's pretty lightweight but it provides a nice
1GB is close-ish to the 1.4GB last reported (over a month ago!) by
http://huonw.github.io/isrustfastyet/mem/.
Are there any workarounds to push the compilation memory down? I'm also
exploring distcc, but IRFY has a bit of semantic ambiguity as to whether or
not it's 1.4GB simultaneous or net
1.4GB peak, consumed by rustc and every child process. The bencher is
currently running after being down for a while, so it will fill in
today. There are no real workarounds.
On Thu, Jun 5, 2014 at 11:13 AM, Ian Daniher explodingm...@gmail.com wrote:
1GB is close-ish to the 1.4GB last reported
Have you considered to use zram? Typically the compression for
compiler memory is over a factor of 3 so that can be an option as the
performance degradation under swapping could be tolerable. A similar
option is to enable zswap, but as the max compression with it is
effectively limited by factor
I appreciate your enthusiasm, but please stop creating new threads that
simply suggest adding major new features to the type system. The vast
majority of type system features that might benefit Rust have been
discussed many times, in excruciating depth, for years.
On 06/05/2014 02:14 AM,
On Thursday, June 5, 2014, kimhyunk...@gmail.com wrote:
I first intended to convert sql! macro to some IteratorOptionint.
However, we don't have typeof(TestTable::a) syntax yet, which means it's
impossible to get the type of a column without creating a dummy instance.
There may be things we
Could be an interesting library!
Kevin
On Jun 1, 2014 4:29 AM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
On Sun, Jun 1, 2014 at 1:04 PM, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-01, at 13:48, Gábor Lehel glaebho...@gmail.com wrote:
It would be possible in theory to teach
Rust is likely to be a great platform on which to implement such new
languages, eventually, though. Be patient. :D
Kevin
On Jun 5, 2014 12:50 PM, Brian Anderson bander...@mozilla.com wrote:
I appreciate your enthusiasm, but please stop creating new threads that
simply suggest adding major
Link to literature: http://www.cs.cmu.edu/~aldrich/plaid/
BTW, Gradual typing, dependent typing, type state (as in Plaid) will be a
cool addition and really harp for this.
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO
What is the syntax for calling a static method of a generic struct
while selecting the the generic parameters explicitly? Apparently
StructType::static_method does not work. For example, consider the
following program:
#[deriving(Show)]
struct TestT { i: int }
implT TestT {
fn new() - TestT
I don't know if there's a better way, but this at least works:
let tmp: Testbool = Test::new();
let t = tmp.test();
println!(t={}, t);
On 2014-06-04, at 10:28, Igor Bukanov i...@mir2.org wrote:
What is the syntax for calling a static method of a generic struct
while selecting the the generic
On Wed, Jun 4, 2014 at 9:28 AM, Igor Bukanov wrote:
What is the syntax for calling a static method of a generic struct
while selecting the the generic parameters explicitly? Apparently
StructType::static_method does not work. For example, consider the
following program:
#[deriving(Show)]
Apparently this works as well:
let t = Test::bool::new().test();
println!(t={}, t);
On 2014-06-04, at 10:50, Tommi rusty.ga...@icloud.com wrote:
I don't know if there's a better way, but this at least works:
let tmp: Testbool = Test::new();
let t = tmp.test();
println!(t={}, t);
On
Thanks, Test::bool::new() works indeed.
On 4 June 2014 09:52, Sebastian Gesemann s.gesem...@gmail.com wrote:
On Wed, Jun 4, 2014 at 9:28 AM, Igor Bukanov wrote:
What is the syntax for calling a static method of a generic struct
while selecting the the generic parameters explicitly? Apparently
Hi,
The Box is a welcome change over ~.
Any way the closure syntax can improve. Instead of having 2 syntaxes be
explicit of what is captured.
let x = 3;
fn fun_arg (arg: int) - () { println!({}, arg + x) } //
cannot capturelet closure_arg = (arg: int)|x| - () { println!({},
arg + x) };
Hi,
It is great you have ADT but can you extend it to have GADTs?
Suminda
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
We'd love to have more advanced type system features (I'm looking
forward to HKT myself), but the focus right now (seems to be) is
cutting out everything that needs to be cut before 1.0. We can add
neat new things after.
___
Rust-dev mailing list
Hi,
I am trying different alternative to kill a task from parent, But I didn't
get any ways to kill a task from its parent.
In the following approach I started worker2 inside worker1 and worker1 from
main. After 1000 miliseconds worker1 dies, but worker2 still continues.
use
Rust tasks do not support being killed at arbitrary points. You'll
have to arrange ahead of time for a please die message to be sent a
long a channel, or a similar scheme for transmitting this information.
On Wed, Jun 4, 2014 at 9:33 AM, Aravinda VK hallimanearav...@gmail.com wrote:
Hi,
I am
I'm trying to run rustc on an arm board, but obviously there's no
precompiled stage0 to build the compiler.
Is there a procedure to cross-compile stage0 on other host machine where I
do have rustc?
--
Sincerely,
Vladimir Farcaller Pouzanov
http://farcaller.net/
Greetings, all.
Looking for ways to have an impact on Rust? The current plan for Rust
defers the creation of some key libraries until after Rust 1.0, but that
doesn't mean we can't start on them now if the interest is out there.
Here are 7 libraries that need to be created soon rather than
Hi,
My thinking is that not to be too premature to get to version 1.0.
My feeling is that there are still quite a few areas where the language
syntax and features can evolve before version 1.0
Suminda
___
Rust-dev mailing list
Rust-dev@mozilla.org
The thought-process is (as I know it)
A) Taking things out is hard, and breaks code
B) 1.0 should be stable, and supported without breakage for a long time
C) Adding things is pretty easy, and doesn't break code
D) A stable release should happen as soon as is reasonable, to get Rust
used and
Some features like 2 closure syntaxes is not appealing for version 1.0 of
the language. You should have a different way to specify capture. I send a
mail reading this also.
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hi,
The initial Type State implementation in Rust was not a great way to get
about it. Please reconsider adding type state like it has been done in the
Plaid language.
Basically you can use traits mechanism to mixin and remove the trait when
methods marked as having state transitions.
Suminda
Thank you for your suggestion, but typestate is not coming back. There
is no room in the complexity budget for another major piece of type
system, and linear types can serve much the same purpose.
On 06/04/2014 10:11 PM, Suminda Dharmasena wrote:
Hi,
The initial Type State implementation in
I'm pretty sure closure*s are *on the list to be addressed before 1.0
See https://github.com/mozilla/rust/issues?milestone=20page=1state=open
for a good idea of our roadmap is before 1.0
On Thu, Jun 5, 2014 at 12:09 AM, Suminda Dharmasena sirin...@sakrio.com
wrote:
Some features like 2 closure
There are at least two tricky aspects to adding GADTs in Rust:
1) Rust implements parametric polymorphism via monomorphization (duplicating
polymorphic functions for each type), but GADTs are really only useful with
polymorphic recursion, which requires a polymorphic function to be applied to a
Is there a canonical example of encoding a state machine into Rust's
substructural types?
Cameron
On Jun 4, 2014, at 10:14 PM, Brian Anderson bander...@mozilla.com wrote:
Thank you for your suggestion, but typestate is not coming back. There is no
room in the complexity budget for another
I find it somewhat jarring to have to spend two lines for the following kind of
imports:
use module::Type;
use module;
So, I suggest we add a nicer syntax for doing the above imports using the
following single line:
use module::{self, Type};
It would probably be a good idea to force the
On Mon, Jun 2, 2014 at 10:09 PM, Matthew McPherrin wrote:
On Mon, Jun 2, 2014 at 8:25 AM, Patrick Walton wrote:
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it feels like there's something wrong
with the language when it doesn't allow multiple mutable references to
the
Consider the following enum:
#[deriving(Clone)]
enum List'a {
Nil,
Next('a List'a)
}
It generates en error:
anon:4:10: 4:22 error: mismatched types: expected `List` but
found `List` (expected -ptr but found enum List)
anon:4 Next('a List'a)
^~~~
note: in
Somewhat. It is due to auto-deref: deriving(Clone) essentially expands to
fn clone(self) - List'a {
match *self {
Nil = Nil,
Next(ref x) = Next(x.clone())
}
}
`x` is of type `List'a`, but the `x.clone()` call auto-derefs
through both layers of
On 03/06/14 05:58 AM, Sebastian Gesemann wrote:
On Mon, Jun 2, 2014 at 10:09 PM, Matthew McPherrin wrote:
On Mon, Jun 2, 2014 at 8:25 AM, Patrick Walton wrote:
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it feels like there's something wrong
with the language when it
+1, I was planning on suggesting this as well.
On Jun 3, 2014 2:16 AM, Tommi rusty.ga...@icloud.com wrote:
I find it somewhat jarring to have to spend two lines for the following
kind of imports:
use module::Type;
use module;
So, I suggest we add a nicer syntax for doing the above imports
In my original post I stated that it feels like there's something wrong with
the language when it doesn't allow multiple mutable references to the same
data, but I didn't really explain why it feels like that. So, I just want to
add this simple example to help explain my position. It is just
On 2014-06-02, at 10:44, Tommi rusty.ga...@icloud.com wrote:
Nothing can go wrong here [..]
I just watched this video https://www.youtube.com/watch?v=awviiko59p8 and now I
get the impression is that perhaps preventing aliasing bugs is more important
than the convenience of unrestricted,
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it feels like there's something wrong
with the language when it doesn't allow multiple mutable references to
the same data, but I didn't really explain why it feels like that. So, I
just want to add this simple example to help
Great Thanks to all,
now i have a more precise idea.
So, to summarize
if the function takes a vector as argument, transforms it, and return it,
with no need for the caller to use the argument
fn my_func(src: Vecu8) - Vecu8
if the functons takes a vector argument and use it just for a temporary
Hi all!
Could someone help me with a question about the [References and lifetime
guide](http://doc.rust-lang.org/guide-lifetimes.html#borrowing-and-enums) (for
0.11.0) which I can't figure out.
In the *Lifetimes* section there is this example:
fn example3() - int {
struct House {
Isn't this MutableVector's mut_split_at
http://doc.rust-lang.org/std/slice/trait.MutableVector.html#tymethod.mut_split_at
that we already have?
On Mon, Jun 2, 2014 at 8:25 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/2/14 12:44 AM, Tommi wrote:
In my original post I stated that it
Would it be possible to get a compile-time error for a `match` branch that can
never be reached due to a previous branch encompassing it. For example, for the
middle branch here:
let n = 0;
match n {
x if x 2 = (),
x if x 1 = (),
_ = ()
}
If this is a too complicated a problem in
Hello all,
I've read this :
http://words.steveklabnik.com/pointers-in-rust-a-guide
I am coming from Java where everything is passed and returned by
reference (except for primitive data types), no choice.
I know that with C, you have to use pointers to avoid passing and
returning by value.
When
On 01/06/14 04:34 AM, Christophe Pedretti wrote:
Hello all,
I've read this :
http://words.steveklabnik.com/pointers-in-rust-a-guide
I am coming from Java where everything is passed and returned by
reference (except for primitive data types), no choice.
I know that with C, you have to
Aw, Gmail makes it so easy to press Reply instead of Reply to all.
See below :)
Hi, Christophe,
Because `Vec` looks like this:
struct VecT {
len: uint,
cap: uint,
data: *mut T
}
its actual size is just three words, so you can freely pass it around
regardless of number of
one of the recent changes with box is that it does placement new. So
generally, this is bad:
fn foo(x: int) - Boxint {
box (x + 1)
}
let y = foo(5);
Because it forces your caller to use a Box. Instead...
fn foo(x: int) - int {
x + 1
}
Because then your caller can choose:
let y =
Well, not possible in the general case, to be more precise. It would be
possible in theory to teach the compiler about e.g. the comparison
operators on built-in integral types, which don't involve any user code. It
would only be appropriate as a warning rather than an error due to the
inherent
On 2014-06-01, at 13:48, Gábor Lehel glaebho...@gmail.com wrote:
It would be possible in theory to teach the compiler about e.g. the
comparison operators on built-in integral types, which don't involve any user
code. It would only be appropriate as a warning rather than an error due to
the
On Sun, Jun 1, 2014 at 1:04 PM, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-01, at 13:48, Gábor Lehel glaebho...@gmail.com wrote:
It would be possible in theory to teach the compiler about e.g. the
comparison operators on built-in integral types, which don't involve any
user code. It
FYI: I did a RFC for separating mut and only some times ago:
https://github.com/rust-lang/rfcs/pull/78#
I invite the interested readers to check it out and read the comments
(notably those by thestinger, aka Daniel Micay on this list).
For now, my understanding was that proposals on the topic
Hi all,
suppose i want to replace the i th character c (this character is ascii, so
represented by exactly one byte) in a String named buf with character 'a'
i can do this
buf =
buf.as_slice().slice_to(i).to_string().append(a).append(buf.as_slice().slice_from(i+1))
if c is any UTF8 character, i
I'm looking for a little borrow-checker advice. Here's a reasonably
minimal program that demonstrates the problem:
extern crate collections;
use collections::HashMap;
struct G {
verts: HashMapint, String,
edges: Vec(int, int),
next_vert_id: int
}
impl G {
fn new() - G {
The simplest thing to do is probably to build an intermediate vector of
vertices to insert and then push them all after you are done iterating over the
edges.
Cameron
On Jun 1, 2014, at 12:48 PM, Nicholas Bishop nicholasbis...@gmail.com wrote:
I'm looking for a little borrow-checker
and using mut_iter() instead of iter() is not enough ?
2014-06-01 22:03 GMT+02:00 Cameron Zwarich zwar...@mozilla.com:
The simplest thing to do is probably to build an intermediate vector of
vertices to insert and then push them all after you are done iterating over
the edges.
Cameron
`mut_iter` only gives you mutable references to the elements of the container;
it doesn’t allow you to reborrow the container itself mutably inside of the
loop.
Cameron
On Jun 1, 2014, at 1:39 PM, Christophe Pedretti christophe.pedre...@gmail.com
wrote:
and using mut_iter() instead of
Building an intermediate would work, but it implies extra overhead. If
this was a large graph instead of just one edge then it could be
expensive to copy from the intermediate back into the original object.
Are there any alternatives to consider?
On Sun, Jun 1, 2014 at 4:48 PM, Cameron Zwarich
It’s difficult to do something better without somewhat breaking the
encapsulation of your graph type, but you could split G into edge and vertex
data structures and have the functions that add vertices / edges operate on
part of . Then given an mut G, you could reborrow the vertex data and the
I haven't tried this at all, but could iterating over the range [ 0,
g.edges.len() ) work?
On Sun, Jun 1, 2014 at 2:26 PM, Cameron Zwarich zwar...@mozilla.com wrote:
It’s difficult to do something better without somewhat breaking the
encapsulation of your graph type, but you could split G
Here's example code:
/src/main.rs:
mod foo;
fn main() {
foo::foo();
}
/src/bar.rs:
pub fn bar() {
}
/src/foo.rs:
mod bar;
pub fn foo() {
bar::bar();
}
This fails:
$ rust-nightly-x86_64-unknown-linux-gnu/bin/rustc -v
rustc 0.11.0-pre-nightly (064dbb9 2014-06-01 00:56:42 -0700)
host:
I haven't tried this at all, but could iterating over the range [ 0,
g.edges.len() ) work?
An interesting suggestion, but doesn't extend easily to other types of
containers like HashMaps.
It’s difficult to do something better without somewhat breaking the
encapsulation of your graph type,
The directory layout of the project should match the module hierarchy. bar
is a submodule of foo so it shouldn't live next to foo in the filesystem.
There are a couple of filesystem setups that will work:
src/
main.rs
foo/
mod.rs
bar.rs
src/
main.rs
foo/
My intent wasn't to make bar a submodule of foo, but rather that foo
bar would be sibling modules (and foo just happens to use bar). Is
there a way to do that?
On Sun, Jun 1, 2014 at 6:56 PM, Steven Fackler sfack...@gmail.com wrote:
The directory layout of the project should match the module
Yep!
main.rs:
mod foo;
mod bar;
fn main() {
foo::foo();
}
foo.rs:
use bar; // this use lets you refer to the bar fn as bar::bar() instead of
::bar::bar()
pub fn foo() {
bar::bar();
}
bar.rs:
pub fn bar() {}
Steven Fackler
On Sun, Jun 1, 2014 at 5:25 PM, Nicholas Bishop
Perfect, thanks Steven.
On Sun, Jun 1, 2014 at 8:27 PM, Steven Fackler sfack...@gmail.com wrote:
Yep!
main.rs:
mod foo;
mod bar;
fn main() {
foo::foo();
}
foo.rs:
use bar; // this use lets you refer to the bar fn as bar::bar() instead of
::bar::bar()
pub fn foo() {
If your string is an ASCII, you can convert between `String` and
`VecAscii` using `to_ascii()` and `as_str_ascii()` methods. You can
then update an individual character in the vector. See `std::ascii`
for related traits.
Codepoint-wise operation is prone to error and I don't think such
methods
In this case I think it would be simpler to just zip the iterator with
range(0, n) than implement a whole Counted iterator.
On May 31, 2014 4:02 AM, Kevin Ballard ke...@sb.org wrote:
I suspect a more generally interesting solution would be a Counted
iterator adaptor that keeps track of how many
I believe this can be done with something like
let mut counted = iter.scan(0, |count, x| { *count += 1; Some(x) });
for x in counted { ... }
println!(I saw {} elements, counted.state)
or even just
let mut count = 0;
{ // scope to restrict the closure's borrow of
Yes, thanks, it's THE solution to my problem
2014-05-31 0:21 GMT+02:00 Kevin Ballard ke...@sb.org:
If I'm interpreting this right, you also need to add a second lifetime
parameter to your ResultSet object. This way the lifetime used for its
reference to the Statement can be different than the
On 5/31/14 10:36 AM, Tommi wrote:
It certainly feels like a failure of the Rust type system that you
cannot have multiple mutating references to the same variable when
the variable is accessed only from a single thread. I know the reason
for this is to prevent iterator invalidation, but this is
Sorry for the brevity, I'm writing this from a phone and I haven't thought of
this issue very thoroughly.
You appear to dislike one of the most fundamental features of Rust, so
I would encourage you to think through ideas such as this before
hastily posting to the mailing list.
The current
Hi all,
i have updated my rust compiler, i have several compilations errors on my
project
1. StrBuf does not exist any more, no problem, i now use String
2. ~ is obsolete, no problem, i use box
3. The last isssue is failed to find an implementation of trait
core::cmp::TotalEq for
Iterator invalidation is a sweet example, which strikes at the heart of C++
developer (those who never ran into it, please raise your hands).
However it is just an example, anytime you have aliasing + mutability, you
may have either memory issues or logical bugs.
Another example of memory
`String` is a complete substitute of the old `~str` (or `Boxstr` or
whatever) in such that `~str` should not be used now. Replace all
occurrence of `~str` with `String`, and `~foo` with
`foo.to_string()`. Almost every function in the standard library,
including those in `std::str`, now returns
Hi, Christophe,
You shouldn't be using `~str` at all, you should use `String`. Also,
`box ` is not a replacement for `~`, they have different types.
The proper replacement is `String::new()` or `.to_string().
Your code in modern Rust will look like this:
/// Contains a list of properties. A
On 2014-05-31, at 22:13, Matthieu Monrocq matthieu.monr...@gmail.com wrote:
Another example of memory issue:
foo(left: OptionBoxstr, right: mut OptionBoxstr) {
let ptr: str = *left.unwrap();
right = None;
match ptr.len() { // Watch out! if left and right
On 2014-05-31, at 20:44, Patrick Walton pcwal...@mozilla.com wrote:
On 5/31/14 10:36 AM, Tommi wrote:
Iterator invalidation (as it's known in C++) is a risk to memory
safety only when some of the memory that is accessible through an
iterator (or a reference) is deallocated. A better type
chars_rev iterator does not exist anymore (std::str::StrSlice) ?
2014-05-31 22:17 GMT+02:00 Vladimir Matveev dpx.infin...@gmail.com:
Hi, Christophe,
You shouldn't be using `~str` at all, you should use `String`. Also,
`box ` is not a replacement for `~`, they have different types.
The
When writing an email stating “your programming language isn’t expressive
enough”, it’s a good idea to include an example program that you would like to
write that is rejected by the current type system. Then people replying to your
email can give you some suggestions on how to best achieve
Try this out:
```
fn main() {
let s = abc.to_string();
for c in s.as_slice().chars().rev() {
println!({}, c);
}
}
```
produces:
```
c
b
a
```
On Sat, May 31, 2014 at 2:46 PM, Christophe Pedretti
christophe.pedre...@gmail.com wrote:
chars_rev iterator does not exist
On 5/31/14 2:44 PM, Tommi wrote:
I don't understand that last sentence. How could you use `transmute` in
safe code given that it's an `unsafe` function?
I mean you could *write* transmute in safe code. Look:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x =
On 2014-06-01, at 1:02, Patrick Walton pcwal...@mozilla.com wrote:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x = Left(other);
let y = match x {
Left(ref mut y) = y,
Right(_) = fail!()
};
*x = Right(value);
References (T) are Copy.
Huon
On 01/06/14 09:42, Tommi wrote:
On 2014-06-01, at 1:02, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x = Left(other);
let y = match x {
Left(ref
On 2014-06-01, at 2:45, Huon Wilson dbau...@gmail.com wrote:
References (T) are Copy.
That didn't occur to me. Okay, I can see how that would be a problem.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I assume what you're trying to say is that we should allow multiple mutable
references to pointer-free data. (Note that, as Huon pointed out, this is not
the same thing as the Copy bound.)
That is potentially plausible, but (a) it adds more complexity to the borrow
checker; (b) it's a fairly
FWIW, I think you could eliminate (c) by prohibiting mutation of sum types.
What case are you thinking of for (e)?
For (d), this would probably have to be distinguished from the current mut
somehow, to allow for truly unique access paths to sum types or shared data, so
you could preserve any
Yes, you could eliminate (c) by prohibiting taking references to the inside of
sum types (really, any existential type). This is what Cyclone did. For (e) I'm
thinking of sum types in which the two variants have different sizes (although
maybe that doesn't work).
We'd basically have to bring
We ought to have something like this for sure.
I wonder if we can do something a little more generic though, perhaps
using FromIterator. Not quite as pretty, but
let x: HashMap = from_iter![(key, val), (key2, val2), (key2, val2)]
A dict! macro could do the same thing but allow for the more
I'm still new to Rust (and even newer to writing macros), but I don't see
how `from_iter!` would be able to figure out what type to return.
I think a `dict!` macro would be worth it for the `=` syntax, even if
`from_iter!` gets implemented. I'm not sure if it could somehow use
`from_iter!`
2014-05-30 5:37 GMT+04:00 Kevin Ballard ke...@sb.org:
It shouldn't.
The for-loop desugaring looks like
match mut st.execute_query() {
__i = loop {
match __i.next() {
None = break,
Some(mut __value) = {
let i = __value;
On May 30, 2014, at 12:12 AM, Vladimir Matveev dpx.infin...@gmail.com wrote:
2014-05-30 5:37 GMT+04:00 Kevin Ballard ke...@sb.org:
It shouldn't.
The for-loop desugaring looks like
match mut st.execute_query() {
__i = loop {
match __i.next() {
None = break,
Hi All,
sorry for my late replay, i am UTC+2
Won't wrapping the first `for` loop into curly braces help?
no
is this a database library you're writing yourself?
yes
My best guess here is that you've accidentally used the wrong lifetime on
your `execute_query()` method, tying the lifetime of
On 2014-05-30, at 4:16, Eric Reed ecr...@cs.washington.edu wrote:
That was what I was referencing in my comment about the compiler getting
scared and confused. Theoretically, it should be allowed and the compiler
would just require you to specify, but rustc may not be there yet.
Are you
A good name would be size(). That would avoid any confusion over various
length definitions, and just indicate how much address space it occupies.
Nathan Myers
On May 29, 2014 8:11:47 PM Palmer Cox palmer...@gmail.com wrote:
Thinking about it more, units() is a bad name. I think a renaming
I think the 'ref' keyword removal is a very good idea. It has bitten
me several times, and the idea that pattern matching something
essentially performs a side effect (moving the value) leaves me
uncomfortable.
Cheers,
Emm
___
Rust-dev mailing list
The manual says that the precedence of `as` operator is lower than that of the
binary `*` operator. Thus I would not expect the following to compile (but it
does):
let a: u16 = 1;
let b: u32 = 2;
let r = a * b as u16;
Since multiplication is supposed to have precedence over casting, I would
What you're overlooking is that patterns are used for more than just
`match` expressions. They can also be used in both assignment statements
and in function/closure signatures. For example, note that `x` and `y` are
the same type in the following program:
fn main() {
let ref x = 3;
1301 - 1400 of 8896 matches
Mail list logo
