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 Counted {
iter: T,
/// In
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
programmin
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
e
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).
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
wrote:
> Hi All,
>
> sorry for my late replay, i am U
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
Sorry, no, I'm deserializing data from the Bitcoin p2p network. There's
a lot of odd quirks (mostly, the integer widths are fairly arbitrary and
sometimes variable-width) which wouldn't be suitable for a general
purpose [de]serializing routine.
Andrew
On Fri, May 30, 2014 at 12:56:59PM -0700,
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 Poels
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 {
On Fri, May 30, 2014 at 2:35 PM, Oleg Eterevsky 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!:
http://doc.rust-lang
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,
..
> 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.
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 orig
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 = foo
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 wrot
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
wrote:
> Hi guys,
>
>
> Take is an iterator adaptor which cuts off the contained iterator after
> some number of elements, always returning None.
>
> I fi
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 P
On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky 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 exceptions are
> e
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
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 p
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 wo
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 wrote:
> The manual says that the precedence of `as` operator is lower than that of
> th
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;
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
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
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 wrote:
Thinking about it more, units() is a bad name. I think a renaming could
make sense, bu
On 2014-05-30, at 4:16, Eric Reed 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 saying that the compiler
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
On May 30, 2014, at 12:12 AM, Vladimir Matveev wrote:
> 2014-05-30 5:37 GMT+04:00 Kevin Ballard :
>>
>> It shouldn't.
>>
>> The for-loop desugaring looks like
>>
>> match &mut st.execute_query() {
>>__i => loop {
>>match __i.next() {
>>None => break,
>>Some(
2014-05-30 5:37 GMT+04:00 Kevin Ballard :
>
> 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;
>
30 matches
Mail list logo