Due to type inference, my assumption is that in many cases the only people
that see the actual type names are the developers creating them and people
reading the docs. I hadn't though about the Reader / Port cases, but those
do seem like pretty reasonable places where you might want to have an
obje
I disagree. Option is precisely the right type because all Option means is
you can get something or nothing.
Sometimes it can make sense to consider 'something' success and 'nothing'
failure, like attempting to parse a string.
Sometimes it can make sense to consider 'nothing' success and 'something
Eric, thats exactly why I suggested the use of the Result or Either type.
Some is a bit misleaning, because the Nothing case is usually means a
failure rather than a success.
On Sat, Dec 21, 2013 at 9:33 PM, Eric Reed wrote:
> IMO the best alternative for a non-blocking send on a bounded chann
IMO the best alternative for a non-blocking send on a bounded channel is
returning an Option.
If you send successfully, you return None.
If you can't send because the channel is full, you return Some(message).
This lets the sender recover the message (important for moveable objects)
and decide how
I prefer the 'no suffix' option and generally agree with Alex.
Iterators aren't special and their iterator behavior is already denoted by
implementing the Iterator trait.
Frankly, aside from documentation where it is clear that something is an
iterator, I'm not sure when a user would even see conc
The reason the Iterator suffix was removed is because when when one is
required to write the type signature it becomes hugely annoying to
keep writing Iterator all the time. Personally I think Alex's idea is
a good way forward.
On Sat, Dec 21, 2013 at 4:35 PM, Kevin Cantu wrote:
> Rust's standard
Rust's standard libs are still pretty thin on their trait hierarchies,
but I'm sure this will change.
Kevin
On Sat, Dec 21, 2013 at 1:30 PM, Palmer Cox wrote:
> Are there examples of structs that implement Iterator that also implement
> other non-Iterator related traits? Although its possible to
Are there examples of structs that implement Iterator that also implement
other non-Iterator related traits? Although its possible to do that, I
can't think of a use case for it off the top of my head. An Iterator
basically represents the state of an ongoing computation and once that
computation is
Iterators are just structs which implement the "Iterator" or a related
trait, right?
These structs which do can also implement lots of other traits, too:
no reason to make -Iter special.
Kevin
On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox wrote:
> I'm not a big fan of Hungarian notation eithe
I'm not a big fan of Hungarian notation either. I'm not sure that having a
naming convention for Iterators is Hungarian notation, however. For
example, if you are doing Windows programming, you'll see stuff like:
DWORD dwFoo = 0;
In this case, the "dw" prefix on the variable indicates that we hav
IMHO Hungarian notation is for things the type system and tooling
cannot deal with. I'm not sure this is one of them...
Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I like Iter suffix, short, and say what it is.
在 2013年12月21日 下午12:51,"Palmer Cox" 写道:
> I noticed recently that there seem to be 3 distinct Iterator naming
> conventions currently in use:
>
> 1. Use the "Iterator" suffix. Examples of this are SplitIterator and
> DoubleEndedIterator.
> 2. Use the "
I think you have the wrong mailing list :) This is for the Rust programming
language (rust-lang.org), not the Rust game.
--
Ziad
On Sat, Dec 21, 2013 at 6:23 AM, Pedro Santos wrote:
> Hello,
>
> Is it possible to some one to explaion why the UK servers are all down ?
> i know the game is a bet
Hello,
Is it possible to some one to explaion why the UK servers are all down ?
i know the game is a beta but because i pay for it and its not free 4 play
i think ppl deserve an explanation why the servers are down for the last 20
hours.
Regards,
Pedro
___
I favor this approach too. As an example, Scala does something similar: a
call to Map() constructs an immutable map object (it is in the "default"
namespace), whereas if you want a mutable Map object, you have to import it
from scala.collection.mutable.Map.
--
Ziad
On Fri, Dec 20, 2013 at 10:50
15 matches
Mail list logo