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
that those are the ones to be used when writing hashes, etc.
Even if they are just aliases of the default int types. If nothing else,
this will allow people to document in their code whether the ints were
supposed to wrap around or not.
Vadim
On Sun, Jun 22, 2014 at 4:12 PM, Patrick Walton pcwal
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
-wrapping ints.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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
constitutes like 90% of all
lifetime parameter usage. Back when we had 'self, Rust sources looked way
less noisy.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
lifetimes
entirely,- there are still cases when they are needed. But as far as I've
seen, those are few and far between.
Thanks for reading,
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
type of borrow that prevents
all object access while it is in scope, similarly to how iterators prevent
mutation of the container being iterated?
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
future at that time or I
won't be able to start writing. And if I don't wait on the read future, I
won't know when I have data available.
-Kevin
On Jan 29, 2014, at 2:03 PM, Vadim vadi...@gmail.com wrote:
After reading about the simultaneous stream reading/writing issue
discussed
On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard ke...@sb.org wrote:
Any number of things.
The use case here is an interactive protocol where writes go in both
directions, and can be initiated in response to external events. The
classic example is an IRC bot. The server can send a message at
into the user buffer, thus avoiding one data copy and the read()
or write() call, which normally would be needed after a select().
On Wed, Jan 29, 2014 at 4:53 PM, Kevin Ballard ke...@sb.org wrote:
On Jan 29, 2014, at 4:16 PM, Vadim vadi...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:55 PM
transformhttp://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069662.html,
though I am not yet sure how portable this would be.
cheers,
Vadim
On Sat, Jan 25, 2014 at 8:58 AM, Bill Myers bill_my...@outlook.com wrote:
Stack management for green tasks has been based in the past first
Hitting a slow path unexpectedly on overflow seems to me like a recipe
for
unpredictable performance, which doesn't seem inline with Rust's usual
goals.
It's certainly better than the process exiting, which is what's going
to happen in real systems when failure occurs. Either that, or
The branch on the overflow flag results in a very significant loss in
performance. For example, I had to carefully write the vector `push`
method for my `VecT` type to only perform one overflow check. With
two checks, it's over 5 times slower due to failed branch predictions.
Huh, that's a
. Let's say we chose '^' for
this purpose, and implemented its' trait for Option, Result, etc. Then one
could write:
let x = foo()^;
or
let y = foo()^.field;
Vadim
On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron li...@ncameron.org wrote:
I agree with Simon that doubling the API
() versions of every API, and many people (including myself),
consider unwrap() too noisy. So...
Vadim
On Wed, Jan 8, 2014 at 1:42 PM, Vadim vadi...@gmail.com wrote:
I can see how '?.' would work when foo() returns a struct, but what about
non-struct types, e.g. Optioni32 ? Also, you'd
would just let it slide for pass-through types like
T, but require annotations in non-generic code.
Not the best solution, but it just bothers me that we worry about the
mutability hazard at the top level of the call chain, but then completely
forget about it inside the callee.
Vadim
On Wed
prefix at call sites? i.e. to avoid
non-const ref badness that C++ has?
Longer version of my question:
Since this question was asked recently by vadim and not really answered
clearly (imo), I'm also including this longer verbose version of my
question.
For example in C the call f(a,b); might
to imply that.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
that for me.
And, judging by the number of C++ projects that ban non-const references
but nave no problem with const ones, I think that a significant proportion
of developers feel similarly.
Vadim
On Sat, Dec 28, 2013 at 10:03 AM, Kevin Ballard ke...@sb.org wrote:
We have to say `mut i` in main
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic,
this should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com
int) {
bar(mut i);
}
fn bar(i: mut int) {
i = i + 1;
}
On Tue, Dec 24, 2013 at 6:10 PM, comex com...@gmail.com wrote:
On Tue, Dec 24, 2013 at 8:17 PM, Vadim vadi...@gmail.com wrote:
I'm again pretty nervous about this, because this is one of the
much-maligned features of C
that would be prettier if we had argument
auto-borrowing, if invocation operator would auto-deref, and if closure
assignment was in scope to be captured inside the closure itself (wouldn't
have to do dummy init of the B var).
cheers,
Vadim
type T's = 's || - int;
fn man_or_boy(k:int) - int {
fn
Right off the bat, I would say that would be prettier if we had argument
auto-borrowing
I'm again pretty nervous about this, because this is one of the
much-maligned features of C++ references.
*Why* is it maligned, though?
and if closure
assignment was in scope to be captured inside the
Not sure what you mean by `self` on `T`. I thought traits can
take self by-value?
On Dec 1, 2013, at 1:22 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/1/13 7:42 AM, Vadim wrote:
Once fn()'s should consume their environment, perhaps it should be
simply self, where Self is non
that this is different for function arguments vs
regular code in the function body. So maybe the right thing to do *is *to
stop moving function parameters by default?
On Tue, Nov 19, 2013 at 5:35 PM, Vadim vadi...@gmail.com wrote:
If the function is not going to mutate it, I don't really care if it's
that reference semantics for pointers combined with foo(mut x);
foo(move y)'; would address the former while not introducing more syntax
noise required to disambiguate the latter.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
with the `ref` keyword).
--
Ziad
On Tue, Nov 19, 2013 at 4:54 PM, Vadim vadi...@gmail.com wrote:
So why did Rust adopt auto-moving instead of explicit moving? If the
second example had to be written as foo(move a) there would be no
confusion. The and the third example should arguably be sort
So in the case of --staticlib, if my Rust library, libmycomp.a, depended on
non-Rust local native library, libfoo.a, would Rust then bundle all modules
from libfoo into libmycomp? Or would it only do so for Rust libraries,
e.g. libstd.a?
On Fri, Nov 15, 2013 at 12:09 AM, Alex Crichton
linking. This could be a companion text file
or maybe a command line option to rustc, which dumps this info from
metadata.
And if I really do want a monolithic library file, I can always create one
with ar, can't I?
Vadim
On Fri, Nov 15, 2013 at 12:12 PM, Alex Crichton a...@crichton.co wrote
of that make any sense?
Vadim
On Tue, Nov 5, 2013 at 9:18 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/5/13 8:32 AM, David Piepgrass wrote:
Segmented stacks aren't the only solution though.
If the concern is many tasks that block for a long time, I imagine a
mechanism to bundle a bunch
to by
unique pointers, which would probably invalidate a lot of existing
assumptions.
Eric
On Wed, Nov 13, 2013 at 12:02 AM, Vadim vadi...@gmail.com wrote:
Hi,
I would like to float a proposal (or three :-), regarding greenlets in
Rust. For those unfamiliar with greenlets
I do realize that. What I am proposing does not require updating pointers
to the moved stack, because there would be none (I believe).
On Wed, Nov 13, 2013 at 10:20 AM, Daniel Micay danielmi...@gmail.comwrote:
On Wed, Nov 13, 2013 at 3:02 AM, Vadim vadi...@gmail.com wrote:
Hi,
I would
On Wed, Nov 13, 2013 at 10:49 AM, Bill Myers bill_my...@outlook.com wrote:
I see several proposals for the future of Rust tasks, and I think one of
the best approaches is being overlooked, and that is something similar to
async in C#
. If
all that were removed from the source, bringing segmented stacks back would
become much more difficult.
On Mon, Oct 21, 2013 at 9:52 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Oct 22, 2013 at 12:37 AM, Vadim vadi...@gmail.com wrote:
Ok, so maybe they should be disabled
, just as segmented stack prologues
do? So what's the difference?
Vadim
On Mon, Oct 21, 2013 at 9:52 PM, Patrick Walton pwal...@mozilla.com wrote:
On 10/21/13 8:48 PM, Daniel Micay wrote:
Segmented stacks result in extra code being added to every function,
loss of memory locality, high
, no?
Vadim
On Mon, Oct 21, 2013 at 3:05 PM, Brian Anderson bander...@mozilla.comwrote:
On 10/21/2013 07:30 AM, Corey Richardson wrote:
I've written a blog post about stack safety and a proposal for how I
think it should be implemented in Rust:
http://cmr.github.io/blog/**2013/10/21/on-stack-safety
Hi,
I don't understand why the following produces an error:
cat test.rs
trait FooT {}
struct X1;
struct X2;
implT: FooX1 FooX2 for T {}
fn main() {}
rustc test.rs
test.rs:6:0: 6:33 error: expected FooX2, but found FooX1 (expected
struct X2 but found struct X1)
test.rs:6 implT: FooX1 FooX2 for
.dll and libpthread-2.dll
from %mingw%\bin into Rust installation directory and run mingw-get
upgrade to go back to latest versions.
Vadim
On Fri, Sep 27, 2013 at 6:09 AM, Renato Lenzi rex...@gmail.com wrote:
Strange thing...
after installing rust 08 on W7 System rustc.exe (or rust.exe
In this talk https://www.youtube.com/watch?v=f9Xfh8pv3Fs cling devs say
that they did implement transactions. However the best you could hope for
is to restore internal process state. You can't do much about external
resources such as file handles, sockets, etc, etc, so I wonder if it's even
parse.rs
stmt_list! { let mut x = 0 ; while x 10 { let y = x + 1 ; x = y } }
parse.rs:18:14: 18:15 error: No rules expected the token: x
parse.rs:18 while x 10 {
^
Am I totally off-base trying to do this with macros? Do I need a syntax
extension?
Vadim
On Wed
= y } }
parse.rs:17:11: 17:15 error: unexpected token: `an interpolated statement`
parse.rs:17 ( $head ; stmt_list!( $($rest)+ ) );
^~~~
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo
/9205.
Brian, would it be acceptable to commit this in order to unblock migration
to latest mingw?
Vadim
On Mon, Sep 16, 2013 at 7:25 AM, Thad Guidry thadgui...@gmail.com wrote:
Good Job on documenting the build steps, Dandy ! Closer and closer we get
to flawless building on Windows
in case unexpected
problems are discovered.
Vadim
On Mon, Sep 16, 2013 at 5:58 PM, Brian Anderson bander...@mozilla.comwrote:
On 09/16/2013 05:39 PM, Vadim wrote:
I've created a patch which allows to build Rust on latest mingw without
manual patching:
https://github.com/vadimcn/rust/commit
this
threadhttp://sourceforge.net/mailarchive/forum.php?thread_name=CAKEnbTNV4iDok-k9Gg-Wmr85utFPxLf4wmAabjJZ1WaCFVE5PQ%40mail.gmail.comforum_name=mingw-w64-public.
I don't think we'll should migrate to it just yet.
Vadim
On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson bander...@mozilla.comwrote
Did you downgrade your GCC as well?
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust#more-info-for-windows-users
https://github.com/mozilla/rust/issues/5878#issuecomment-22838907
On Sun, Aug 25, 2013 at 6:39 AM, Sun daetalu...@gmail.com wrote:
Hi there,
On my
When I try to use an extern function defined in another crate,
(specifically, std::libc::funcs::extra::kernel32::OpenProcess in my case),
Rust seems to generate a direct call to that function, and then linking
fails because of unresolved symbols. My expectation is that the call
would go first to
Oh, ok, so this will be fixed? Any idea when? :-)
On Thu, Aug 22, 2013 at 2:44 PM, Brian Anderson bander...@mozilla.comwrote:
On 08/22/2013 02:04 PM, Vadim wrote:
When I try to use an extern function defined in another crate,
(specifically, std::libc::funcs::extra::**kernel32
, but on the plus side, this is a more general approach,
and we could get both generators and asyncs out of it in one swoop.
Hmm, come to think about it, couldn't this be done with a syntax extension?
Vadim
On Sun, Aug 11, 2013 at 11:53 AM, Michael Woerister
michaelwoeris...@gmail.com wrote
On Thu, Jun 6, 2013 at 4:13 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Jun 6, 2013 at 6:19 PM, Vadim vadi...@gmail.com wrote:
Based on my experience with iterators in other languages, I would like
throw
in the following idea:
pub trait BlockyIteratorA
On Wed, Jun 5, 2013 at 9:09 PM, Daniel Micay danielmi...@gmail.com wrote:
All kinds of external iterators implement the following trait, whether
they are
a fibonacci number generator, a reverse iterator over a vector or iterator
over
a range in a sorted set:
pub trait IteratorA {
calling convention on
function pointers, and you can't generate COM vtables without that. Once
v0.7 is out, I'll try again.
Vadim
On Mon, Jun 3, 2013 at 5:04 AM, Alexandre Mutel alexandre_mu...@live.comwrote:
Hi,
I have not seen any reference about this, so sorry If I'm posting a
question
the reference to it, it won't be returned to the
free list until I/O completes.
4. When I/O is complete, the future get resolved and all attached
continuations are run.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo
behavior of unique
pointers. I am not entirely sure how by-move vs by-copy is decided, but
according to
thishttp://static.rust-lang.org/doc/rust.html#moved-and-copied-typesRust
would choose by-copy.
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
when timeout expires. .NET provides
standard infrastructure for this, and I think that Rust will need one too.
HTH,
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
was going to look into adding support for traits, enums etc after that,
but since you can work on this full time, I'd love to hand this part over
to you.
When are you starting?
Vadim
On Wed, May 29, 2013 at 8:01 AM, Michael Wörister
michaelwoeris...@gmail.com wrote:
Hi everyone,
I wanted
Thanks for your response Niko. A couple more questions if you don't mind:
On Wed, May 1, 2013 at 10:51 AM, Niko Matsakis n...@alum.mit.edu wrote:
Hello,
Unfortunately, I accidentally deleted a message from Vadim that I
wanted to reply to. However, it had strayed from the topic
Hi Graydon,
How does Rust currently represent its' pointers to vectors? Based on what
I've seen in the library, it seems that ~[T] and @[T] are plain pointers
(with size stored in the pointee), but [T] is a fat pointer, i.e. a
(ptr,len) pair. Is this correct?
On Tue, Apr 30, 2013 at 12:22 PM,
Niko,
- Does immutable mean that the referenced object cannot change forever,
even after current function has returned?
Is it possible in Rust to create a hash that stores its' keys by borrowed
reference (assuming that the hash does not outlive contained keys) and be
assured that the keys will not
a function is called). Probably
not as simple as I describe this, especially if one wants to get rid of the
second indirection, but possible. Had this option been considered?
On Tue, Apr 30, 2013 at 3:16 PM, Brian Anderson bander...@mozilla.comwrote:
On 04/26/2013 04:40 PM, Vadim wrote
I share your concern. It's likely that Rust tasks will never scale as well
as Erlang and I suspect that we will ultimately want an async API that does
not impose the expense of 1 task per I/O stream. I hope though that the
current approach will scale 'pretty well'.
Is there something
What if Result implemented the Drop trait and fail()'ed in drop() unless
it's been disarmed by calling some method (get_err?) which indicates that
the error has been observed?
On Thu, Apr 25, 2013 at 5:30 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/25/13 5:29 PM, Brian Anderson wrote:
is not a part of the language spec, developers
cannot rely on it, and will continue using 's everywhere, just in case.
Kind of like tail recursion optimization is pretty useless unless
guaranteed by the language.
Vadim
On Thu, Apr 4, 2013 at 2:24 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/4/13 2
assignments, but this adds so much line noise!
On Thu, Apr 4, 2013 at 4:13 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Apr 4, 2013 at 6:05 PM, Vadim vadi...@gmail.com wrote:
What's so confusing about this? I agree that parameter modes had too
many
options to think about
Hi,
I saw a
posthttp://www.reddit.com/r/programming/comments/17hqg4/a_little_bit_rusty_practical_approach_on_rust/c86xyorby
Patrick Walton last week on Reddit in which he implied that it is
possible to convert Rust enumerator function into a Java-style iterator by
applying some magic transformer
So right now there is no way to implement, say, lock-step iteration of two
containers, without first copying contents of one of them into a vector?
On Mon, Feb 4, 2013 at 12:15 PM, Patrick Walton pwal...@mozilla.com wrote:
On 2/4/13 11:34 AM, Vadim wrote:
Hi,
I saw a post
http
Hi,
Am I totally off-base in expecting the following to work?
macro_rules! gen_mod(
(
$name:ident
{
$( $fun:item )+
}
) =
(
mod $name
{
$( $fun )+
}
)
)
gen_mod!(
MyMod
{
fn Foo() - u32 {}
!).
Vadim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
74 matches
Mail list logo
