Re: [rust-dev] RFC: Conventions for "well-behaved" iterators

2014-02-13 Thread Olivier Renaud
As you said, the type system can not enforce this rule, that's why the documentation have no choice but to say the behavior is undefined. If the code you write relies on None being returned forever, then you should use the Fuse iterator adaptor, that wraps an existing iterator and enforces this be

Re: [rust-dev] Proposed API for character encodings

2013-09-21 Thread Olivier Renaud
Le samedi 21 septembre 2013 07:59:26 Simon Sapin a écrit : > Le 20/09/2013 20:07, Olivier Renaud a écrit : > > I have one more question regarding the error handling : in DecodeError, > > what does 'input_byte_offset' mean ? Is it relative to the > > 'invalid_b

Re: [rust-dev] Proposed API for character encodings

2013-09-20 Thread Olivier Renaud
Le vendredi 20 septembre 2013 11:52:14 Simon Sapin a écrit : > Le 13/09/2013 23:03, Simon Sapin a écrit : > > /// Takes the invalid byte sequence. > > /// Return a replacement string, or None to abort with a DecodeError. > > condition! { > > > > pub decoding_error : ~[u8] -> Option<~str>; >

Re: [rust-dev] Proposed API for character encodings

2013-09-20 Thread Olivier Renaud
Le vendredi 20 septembre 2013 11:47:04 Simon Sapin a écrit : > Le 20/09/2013 10:18, Olivier Renaud a écrit : > > I really like the API you are proposing. In particular, the error handling > > is close to what I was expecting from such an API. > > > > I have some remarks

Re: [rust-dev] Proposed API for character encodings

2013-09-20 Thread Olivier Renaud
I really like the API you are proposing. In particular, the error handling is close to what I was expecting from such an API. I have some remarks, though. Is there a reason for encoders and decoders to not be reusable ? I think it would be reasonable to specify that they get back to their initi

Re: [rust-dev] Runtime cost of Option

2013-05-29 Thread Olivier Renaud
You will find some more informations in this recent Stackoverflow question : http://stackoverflow.com/q/16504643/112053 Le mercredi 29 mai 2013 10:53:41 Ziad Hatahet a écrit : > Hi all, > > Does using Option incur a runtime cost (like increased memory usage) > compared to a hypothetical case if

Re: [rust-dev] Boxed traits and generics.

2013-05-23 Thread Olivier Renaud
Hi, I am not the OP, but this question made me curious. If I understand the problem correctly, the type system makes a strong distinction between an @Struct and an @Trait. And ptr_eq seems to accept @Struct only. How can this restriction be inferred from the signature of ptr_eq ? Is this becau

Re: [rust-dev] RFC: User-implementable format specifiers w/ compile-time checks

2013-05-09 Thread Olivier Renaud
As for that library, I heavily suggest letting translators manipulate Rust code directly. I see it as no more difficult than asking them to learn a special micro-language that keeps evolving and pattern-matching is really adapted for the task at hand. I'd like to react to this. If the translator

Re: [rust-dev] Re : Re: RFC: User-implementable format specifiers w/ compile-time checks

2013-05-04 Thread Olivier Renaud
> Instead, we could perfectly imagine a "gettext-like" equivalent that takes > both an "original" format string (to be translated) *and* its arguments and > then will use fmt! under the hood to produce a fully translated string to > be fed to the Writer instance. I'm sorry, but I don't see how you

Re: [rust-dev] Re : Re: RFC: User-implementable format specifiers w/ compile-time checks

2013-05-04 Thread Olivier Renaud
> On 2013-05-04, at 13:15 , Olivier Renaud wrote: > > Gettext is indeed dependent on the fact that the format syntax allows > > positional parameters. > Not really, since gettext does not do formatting it does not care and > because different languages may need to reorder pa

[rust-dev] Re : Re: RFC: User-implementable format specifiers w/ compile-time checks

2013-05-04 Thread Olivier Renaud
> Hi, > > 2013/5/3 Graydon Hoare > > > (Erm, it might also be worthwhile to consider message catalogues and > > locale-facets at this point; the two are closely related. We do not have a > > library page on that topic yet, but ought to. Or include it in the lib-fmt > > page.) > > If you are tal

[rust-dev] Re : RFC: Pattern matching binding operator

2013-05-03 Thread Olivier Renaud
Maybe we can consider `:=`, if `=` alone is ambiguous.   - Message d'origine - De : Patrick Walton Envoyés : 03.05.13 03:12 À : rust-dev@mozilla.org Objet : [rust-dev] RFC: Pattern matching binding operator Hi everyone, There's consensus that `@` (imported from Haskell) is a bad binding

[rust-dev] Re : Renaming of core and std

2013-04-24 Thread Olivier Renaud
Considering the content of the current libstd, I think "util" is indeed an appropriate name for this module. Some other propositions : - "base" - "rust" - "platform" - "stock" > Maybe it is from spending too much time with java, but I tend to name those > kind of libs `util`, > because often w

[rust-dev] Re : Re: wanted libraries

2013-04-08 Thread Olivier Renaud
right, the page is writeable. Actually, I was seeing all pages as writeable except this one. Certainly a mistake on my part. Sorry about that, I'll edit the wiki directly, then. Cheers, Olivier Renaud ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] wanted libraries

2013-04-08 Thread Olivier Renaud
with a configurable degree of strictness * Simple (yet powerful) search on a filesystem (eg Ruby's [glob]) * A simple tokenizer/file parser * Support to read/write zip and tar file formats (not only the gzip algorithm) Olivier Renaud ___ [wanted libraries] https://github.com/mozilla/rust/wiki/No

[rust-dev] Re : Re: A question about using uint::range_rev()

2013-03-06 Thread Olivier Renaud
Hi, Would it be possible to leverage the macro system, so that a range can be expressed using an intuitive syntax ? Something like : for range!(0 <= x < size) { io::print(x); } or for range!(10 > v >= 0) { io::print(v); } - Message d'origine - De : Niko Matsakis Envoyés : 06.03.13