Hi,
Is there any way to make Rust's fmt module to consume format template
specified at runtime?
This might be useful for localization of format!'ed strings, or, if one
wants to use format! as a rudimentary template engine.
___
Rust-dev mailing list
I wasn't thinking of subtyping u32w to u32. I actually don't think that
u32 should be convertible to u32w (or vice-versa) without an explicit
cast. For array slices, it would have to be a transmute-like function,
e.g. fn as_wrapping'a(s:'a [u32])-'a [u32w] { unsafe { transmute(s) } }
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non-wrapping calculations in the
same
:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non
Makes sense, but I am curious, how do you see adding this post-1.0? Would
you:
- add overflow-checked int types and tell everybody to use them instead of
the default ones from that point on
- declare that in Rust2 integers are overflow-checked, and have everybody
port their Rust1 code. (Well,
On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging
This is assuming that foo and bar are fn(RCint), right?
In normal use I would expect them to be fn(int) ot fn(int), unless they
need to retain a reference. And in the latter case I would make them
fn(mut RCint) and clone() internally.
On Sat, Jun 21, 2014 at 10:52 AM, Igor Bukanov i...@mir2.org
My 2c:
The world is finally becoming security-conscious, so I think it is a only
matter of time before architectures that implement zero-cost integer
overflow checking appear. I think we should be ready for it when this
happens. So I would propose the following practical solution (I think
Gabor
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 05:21 PM, Vadim Chugunov wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a
only matter of time before architectures that implement zero-cost
integer overflow checking
Regarding the original idea: Why use a whole bit, when you only need one
value out of all possible type's values? For example, for floats, one of
the NaNs could be used for this purpose without any issues with overflow as
would happen in your proposal.
Regarding which types?: Perhaps this
By the way, I didn't see any discussion of the HasPrefix/Coercible
proposalhttps://github.com/mozilla/rust/issues/9912#issuecomment-36073562in
the workweek minutes. Did anybody bring it up at all?
Vadim
On Tue, Mar 11, 2014 at 2:30 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I can't help but
11 matches
Mail list logo
