Re: [rust-dev] cannot borrow `st` as mutable more than once at a time

2014-05-30 Thread Vladimir Matveev
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;

Re: [rust-dev] cannot borrow `st` as mutable more than once at a time

2014-05-30 Thread Kevin Ballard
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,

Re: [rust-dev] cannot borrow `st` as mutable more than once at a time

2014-05-30 Thread Christophe Pedretti
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

Re: [rust-dev] Function overloading is necessary

2014-05-30 Thread Tommi
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

Re: [rust-dev] How to find Unicode string length in rustlang

2014-05-30 Thread Nathan Myers
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

Re: [rust-dev] The meaning of 'box ref foo' ?

2014-05-30 Thread Emmanuel Surleau
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

[rust-dev] Confused about the precedence of 'as' operator

2014-05-30 Thread Tommi
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

Re: [rust-dev] The meaning of 'box ref foo' ?

2014-05-30 Thread Benjamin Striegel
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;

Re: [rust-dev] Confused about the precedence of 'as' operator

2014-05-30 Thread Benjamin Striegel
The manual also says that `as` somehow has a lower precedence than `*` and yet a higher precedence than `+`, which would be hilarious madness. Don't trust the manual. On Fri, May 30, 2014 at 11:02 AM, Tommi rusty.ga...@icloud.com wrote: The manual says that the precedence of `as` operator is

Re: [rust-dev] Confused about the precedence of 'as' operator

2014-05-30 Thread Andrew Poelstra
I did not know that the manual agrees with me, but I've noticed the existing behaviour and find it very unintuitive. Andrew On Fri, May 30, 2014 at 06:02:51PM +0300, Tommi wrote: The manual says that the precedence of `as` operator is lower than that of the binary `*` operator. Thus I

Re: [rust-dev] Confused about the precedence of 'as' operator

2014-05-30 Thread Patrick Walton
On 5/30/14 8:02 AM, Tommi wrote: 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

[rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Andrew Poelstra
Hi guys, Take is an iterator adaptor which cuts off the contained iterator after some number of elements, always returning None. I find that I need to detect whether I'm getting None from a Take iterator because I've read all of the elements I expected or because the underlying iterator ran dry

Re: [rust-dev] A few random questions

2014-05-30 Thread Matthieu Monrocq
On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky o...@eterevsky.com wrote: Since browsers were brought up, here is the Google C++ style guide on exceptions: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions As someone who works for Google, I can attest, that

Re: [rust-dev] How to find Unicode string length in rustlang

2014-05-30 Thread Matthieu Monrocq
Except that in C++ std::basic_string::size and std::basic_string:length are synonymous (both return the number of CharTs, which in std::string is also the number of bytes). Thus I am unsure whether this would end up helping C++ developers. Might help others though. On Fri, May 30, 2014 at 2:12

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Evan G
Instead of using a for statement, try looping over a custom iterator that returns an Enum. On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra apoels...@wpsoftware.net wrote: Hi guys, Take is an iterator adaptor which cuts off the contained iterator after some number of elements, always

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Steven Fackler
It may not fulfill your exact use case, but you can get this in a way: let mut foo = bar.iter().peekable(); { let mut limit_foo = foo.by_ref().limit(50); for baz in limit_foo { ... } } if foo.is_empty() { ... } Steven Fackler On Fri, May 30, 2014 at 9:51 AM, Evan G

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Andrew Poelstra
Hi, thanks, this works well for me. I think you mean .take() rather than .limit(). On Fri, May 30, 2014 at 09:57:50AM -0700, Steven Fackler wrote: It may not fulfill your exact use case, but you can get this in a way: let mut foo = bar.iter().peekable(); { let mut limit_foo =

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Andrew Poelstra
Oh, I sent my earlier message prematurely. The problem here is that I want to move the original iterator forward by the appropriate amount (not one further), since I'm passing a iter.by_ref() to each of my deserialization routines in turn. It seems that if I use .peekable() I either move the

Re: [rust-dev] A few random questions

2014-05-30 Thread Oleg Eterevsky
Personally, I've found exceptions too unwieldy. As I mentioned, the issue of catching an exception is now, how do I recover ?. In my experience it's not really a problem. Usually you just gracefully report an error and either exit the program, or write error to log and stop the operation.

[rust-dev] EnumSet, CLike and enums

2014-05-30 Thread Igor Bukanov
Is it possible to somehow automatically derive collections::enum_set::CLike for a enum? The idea of writing impl CLike for MyEnum { fn to_uint(self) - uint { return *self as uint; } fn from_uint(n: uint) - Flag { match n { 0 = EnumConst1, ...

Re: [rust-dev] A few random questions

2014-05-30 Thread comex
On Fri, May 30, 2014 at 2:35 PM, Oleg Eterevsky o...@eterevsky.com wrote: I can see the advantages of this solution. The only thing I don't see is how to pass any meaningful state with an error. Not sure if you know this, but you can pass any object to the single-argument version of fail!:

Re: [rust-dev] EnumSet, CLike and enums

2014-05-30 Thread Matthieu Monrocq
I advise you to check the tests accompanying EnumSet (in the source code): http://static.rust-lang.org/doc/master/src/collections/home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcollections/enum_set.rs.html#144-158 They show a simple implementation: impl CLike for Foo {

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Erick Tryzelaar
Slightly off topic, what kind of deserialization are you working on? If it's a generic deserializer, I'm putting together a prototype for https://github.com/rust-lang/rfcs/pull/22 in my https://github.com/erickt/rust-serde repository. Maybe we can collaborate. On Friday, May 30, 2014, Andrew

Re: [rust-dev] Confused about the precedence of 'as' operator

2014-05-30 Thread Steve Klabnik
Yup. The manual should not be trusted. We'll fix it! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] cannot borrow `st` as mutable more than once at a time

2014-05-30 Thread Kevin Ballard
I'm assuming that Statement has its own lifetime parameter? And that's the 'a you're using here? Try using a new lifetime. pub fn execute_query'b('b mut self) - ResultSelf'b; -Kevin On May 30, 2014, at 1:54 AM, Christophe Pedretti christophe.pedre...@gmail.com wrote: Hi All, sorry for

Re: [rust-dev] cannot borrow `st` as mutable more than once at a time

2014-05-30 Thread Kevin Ballard
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 lifetime on the Statement type itself (I assume Statement has a lifetime to refer to the database).

Re: [rust-dev] The meaning of 'box ref foo' ?

2014-05-30 Thread Kevin Ballard
Not only this, but match patterns are also extremely often used intentionally to move values. The trivial example is something like match some_opt_val { Some(x) = do_something_with(x), None = default_behavior() } By-ref matching is actually the more infrequent type of matching in my

Re: [rust-dev] How to find Unicode string length in rustlang

2014-05-30 Thread Kevin Ballard
This is a very long bikeshed for something which there's no evidence is even a problem. I propose that we terminate this thread now. If you believe that .len() needs to be renamed, please go gather evidence that's compelling enough to warrant breaking tradition with practically every

Re: [rust-dev] Detection of early end for TakeIterator

2014-05-30 Thread Kevin Ballard
I suspect a more generally interesting solution would be a Counted iterator adaptor that keeps track of how many non-None values it's returned from next(). You could use this to validate that your Take iterator returned the expected number of values. pub struct CountedT { iter: T, ///