Hello Kamlesh,
This mailing list is more-or-less dead; please consider asking your
questions on https://users.rust-lang.org/.
Regards
On Thu, Oct 3, 2019 at 5:37 AM kamlesh kumar
wrote:
> why does optimization removes overflow checks?
> consider below testcase
> $cat test.rs
> fn fibonacci(n:
Hello Eric,
Please note that the rust-dev list is (for better or worse) abandonned.
You may ask questions on either IRC (
https://chat.mibbit.com/?server=irc.mozilla.orgchannel=%23rust), the users
forum (https://users.rust-lang.org/) or StackOverflow.
You may also ask on Reddit
for responding.
you mentioned that rust supports some object-oriented concepts.
may i know which?
also, deviating a bit off-topic, would a decent grasp of functional
programming be a pre-requisite to learning rust?
thanks,
~mayuresh
On 2015-01-11 17:21, Matthieu Monrocq wrote:
Hello
Hello Mayuresh,
The problem with your question is dual:
- OO itself is a fairly overloaded term, and it is unclear what definition
you use for it: Alan Kay's original? The presence of inheritance? ...
- Just because a language supports OO concepts does not mean that it ONLY
supports OO
str is simply a pair (length, pointer).
The reason that even for a literal the length is packed as an argument is
that str does not ONLY work for literals (complete type 'static str) but
for any slice of characters, such as those produced by String::as_slice()
in which case the lifetime is
Hello,
To be clear: there is no such thing as stack/heap in C and C++, there are
automatic variable and dynamically allocated variables, the former having
their lifetime known statically and the latter not...
Whether a particular compiler chooses to use the stack or heap for either
is its free
On Wed, Nov 19, 2014 at 2:42 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
Hi Paul,
On Tue, Nov 18, 2014 at 03:31:17PM -0500, Paul Stansifer wrote:
It's not so much the speed of the parser that is the matter, but the
fragility
of the grammar. The less lookahead that's required,
It's completely unnecessary actually.
If a method requires a XSS-safe string, then it should take the
XssSafeString parameter, which would implement DerefString and would be
built from a String by a method performing the necessary escaping.
If a method requires a SQL-safe string... ah no, don't
On Fri, Sep 19, 2014 at 6:13 AM, Daniel Micay danielmi...@gmail.com wrote:
On 19/09/14 12:09 AM, Lee Wei Yen wrote:
Hi all!
I’ve just started learning to use Rust now, and so far it’s been
everything I wanted in a language.
I saw from the docs that the num::bigint::BigInt type has
While not possible today, there is actually nothing preventing you to
create a safe alternative (or even improving format so it works in this
way).
In a sense, a formatting function has two set of inputs:
- the format itself, from which you extract a set of constraints (expected
type-signature)
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right whenever
going from one mode to the other is going to be a lot of boilerplate.
Instead, why not
On Wed, Jun 18, 2014 at 6:22 PM, Steve Klabnik st...@steveklabnik.com
wrote:
In case of trivial entities
The problem with this is what's trivial to you isn't trivial to someone
else.
think about the amount of update this may make necessary in case Rust
language syntax changes.
Could there be a risk in using JSR310 as a basis seeing the recent
judgement of the Federal Circuit Court that judged that APIs were
copyrightable (in the Google vs Oracle fight over the Java API) ?
-- Matthieu
On Sat, Jun 7, 2014 at 6:01 PM, Bardur Arantsson s...@scientician.net
wrote:
On
On Sun, Jun 1, 2014 at 1:04 PM, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-01, at 13:48, Gábor Lehel glaebho...@gmail.com wrote:
It would be possible in theory to teach the compiler about e.g. the
comparison operators on built-in integral types, which don't involve any
user code. It
FYI: I did a RFC for separating mut and only some times ago:
https://github.com/rust-lang/rfcs/pull/78#
I invite the interested readers to check it out and read the comments
(notably those by thestinger, aka Daniel Micay on this list).
For now, my understanding was that proposals on the topic
Iterator invalidation is a sweet example, which strikes at the heart of C++
developer (those who never ran into it, please raise your hands).
However it is just an example, anytime you have aliasing + mutability, you
may have either memory issues or logical bugs.
Another example of memory
On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky o...@eterevsky.com 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
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
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 {
Does this mean that the desugaring of the for loop is incorrect ? Or at
least, could be improved.
On Thu, May 29, 2014 at 8:22 PM, Vladimir Matveev dpx.infin...@gmail.com
wrote:
Hi, Christophe,
Won't wrapping the first `for` loop into curly braces help? I suspect
this happens because of
It's been discussed, but there is still discussion on the best way to
achieve this.
At the moment, you should be able to get around it using Peano numbers [1]:
struct Zero;
struct SuccT;
struct MatrixT, M, N {
data: VecT,
}
fn cofactorT, M, N(
m: MatrixT, SuccM, SuccN,
row: int,
On Sat, May 24, 2014 at 9:06 AM, Zoltán Tóth zo1...@gmail.com wrote:
Alexander, your option 2 could be done automatically. By appending
postfixes to the overloaded name depending on the parameter types.
Increasing the number of letters used till the ambiguity is fully resolved.
What do you
And let's not forget the ever useful
https://github.com/bvssvni/rust-emptyto get a pre-made Makefile for
rust.
On Sat, May 17, 2014 at 1:11 PM, Artella Coding
artella.cod...@googlemail.com wrote:
http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/
On Sat, May 17, 2014
Hello,
My first instinct would be: don't... but in the name of science...
Have you tried looking at Stack Overflow ? Just googling around I found:
http://stackoverflow.com/questions/19605132/is-it-possible-to-use-global-variables-in-rustwhich
allows you to have a global variable and from there a
On Wed, May 14, 2014 at 2:25 PM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Hi,
On 02/05/2014 00:03, John Downey wrote:
I have actually always been a fan of how .NET did this. The System.String
type
is opinionated in how it is stored internally and does not allow anyone to
change
I agree that a protable terminal would be sweet, however the terminal and
shell are only half the story: you then need a uniform set of tools behind
the scenes else all your scripts fail.
I would like to take the opportunity to point out Mosh [1] as an existing
(and recent) shell, it might make
On Mon, Apr 14, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.comwrote:
On 14/04/14 12:41 PM, Matthieu Monrocq wrote:
Memory fragmentation is a potential issue in all languages that not use
a Compacting GC, so yes.
It's much less of an issue than people make it out to be on 32-bit
Memory fragmentation is a potential issue in all languages that not use a
Compacting GC, so yes.
There are some attenuating circumstances in Rust, notably the fact that
unless you use a ~ pointer the memory is allocated in a task private heap
which is entirely recycled at the death of the task,
Hello,
As far as I know in Rust, a thread (green or not) that enters an infinite
loop without I/O is forever stuck. The only available option to stop it is
to have the OS kill the process (CTRL+C).
In my day job, all our servers services are time-bounded and any that
exceeds its time bound is
On Thu, Mar 27, 2014 at 8:12 PM, Tommi rusty.ga...@icloud.com wrote:
[The following post has nothing to do with thread. I'm posting it here
because my new posts to this mailing list don't go through (this happens to
me a lot). Replies to existing posts tend to go through, thus I'm hijacking
On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel cg.wowus...@gmail.com wrote:
aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
and hope dearly I haven't committed a social faux pas.
That's interesting. You're kinda looking for exception handling in rust!
Unfortunately
On Tue, Mar 25, 2014 at 6:00 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type
I would note that Rust macros are actually working with structural typing:
the expanded macro cannot be compiled unless the expressions/statements it
results in can be compiled.
Regarding Scala here, it seems a weird idea to ask that each and every
method should copy+paste the interface. We all
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote
Hi Eric,
Coming back on memory; I presented two designs:
- in the first one, you have a tag at each level of the hierarchy, which
indeed uses more memory for deep hierarchies but means that a type only
knows about its immediate children
- in the second one, you have a tag only at the root of
I must admit I really like the *regularity* this brings to Rust. There is
nothing more difficult to reason about that an irregular (even if
reasonable) interface simply because one must keep all the rules in mind at
any time (oh and sorry, there is a special condition described at page 364
that
On Sun, Feb 9, 2014 at 12:15 PM, Renato Lenzi rex...@gmail.com wrote:
Always talking about read write i noticed another interesting thing:
use std::io::buffered::BufferedReader;
use std::io::stdin;
fn main()
{
print!(Insert your name: );
let mut stdin =
On Mon, Feb 3, 2014 at 8:41 AM, Gábor Lehel glaebho...@gmail.com wrote:
On Mon, Feb 3, 2014 at 7:55 AM, Corey Richardson co...@octayn.net wrote:
Default typarams are awesome, but they're gated, and there's some
concern that they'll interact unpleasantly with extensions to the type
system
On Sun, Feb 2, 2014 at 6:08 PM, Benjamin Striegel ben.strie...@gmail.comwrote:
After sleeping on it I'm not convinced that this would be a net
improvement over our current situation. With a few caveats I'm really
rather happy with the syntax as it is.
On Sun, Feb 2, 2014 at 8:55 AM, Jason
On Thu, Jan 30, 2014 at 6:33 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Jan 30, 2014 at 12:27 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
Hello,
Segmented stacks were ditched because of performance issues that were
never
fully resolved, especially when every
On Mon, Jan 27, 2014 at 11:41 PM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
On Mon, Jan 27, 2014 at 9:33 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Mon, Jan 27, 2014 at 3:39 AM, Brian Anderson bander...@mozilla.comwrote:
Consensus is that the `do` keyword
On Mon, Jan 27, 2014 at 3:39 AM, Brian Anderson bander...@mozilla.comwrote:
People interested in Rust are often looking for ways to have a greater
impact on its development, and while the issue tracker lists lots of stuff
that one *could* work on, it's not always clear what one *should* work
On Tue, Jan 14, 2014 at 5:56 AM, comex com...@gmail.com wrote:
On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller trop...@bluewin.ch wrote:
intl1,u1 + intl2,u2 = intl1+l2,u1+u2
...
If the result does not fit into an int the compiler throws an error.
To resolve an error, you can:
-
On Tue, Dec 31, 2013 at 6:16 AM, Patrick Walton pcwal...@mozilla.comwrote:
Can someone address Simon Marlow's point here?
https://plus.google.com/10955911385859313/posts/FAmNTExSLtz
unbuffered channels are synchronous in the sense that both reader
and writer must be ready at the same
On Tue, Dec 31, 2013 at 6:46 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/30/13 8:46 PM, Christian Ohler wrote:
To address the last sentence – bounded channels with default size 0
_do_ minimize the fallout of this design: The program would reliably
deadlock every time it is tested
On Thu, Dec 19, 2013 at 7:23 PM, Kevin Ballard ke...@sb.org wrote:
Here’s an example from where I use an infinite queue.
I have an IRC bot, written in Go. The incoming network traffic of this bot
is handled in one goroutine, which parses each line into its components,
and enqueues the result
stuff can use a space available event to unblock)
I cannot see another interesting primitive, at the moment.
-- Matthieu
On Thu, Dec 19, 2013 at 7:25 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Thu, Dec 19, 2013 at 7:23 PM, Kevin Ballard ke...@sb.org wrote:
Here’s an example
Hi Manuel,
I must say that on a conceptual point of view I like the approach, keeping
one's libraries up to date is the only way to go, however I am afraid that
you are glossing over certain details here:
- you assume that the source code is available, this is a problem if I am
using a 3rd party
On Sat, Nov 9, 2013 at 8:13 PM, Simon Ruggier simo...@gmail.com wrote:
Hi all, I've tentatively come up with a design that would allow the sender
to reallocate the buffer as necessary, with very little added performance
cost. The sending side would bear the cost of reallocation, and there
I really like the idea of a task being a sandbox (if pure/no-unsafe Rust).
It seems (relatively) easy for a task to keep count of the number of bytes
it allocated (or the number of blocks), both heap-allocated and
stack-allocated blocks could be meshed together there (after all, both
consume
If I may suggest, rather than blocking the sender in case the channel is
full, I suggest simply returning an error (or raising a condition)
immediately.
This is both extremely simple (for the channel implementer) and heavily
customizable (for the user).
It seems certainly much easier than
On Thu, Oct 24, 2013 at 4:18 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB
on 64 bit).
Actually, goroutines have a default stack size of 8kb since 1.2.
Also, applicable to this discussion, in 1.3 Go will be moving
It seems to me that maybe there are several concepts/changes that are
discussed at once, and it would be possible to nitpick.
Personally, when I think of unifying calls, I only think of having
foo.bar(baz) being strictly equivalent to bar(foo, baz); nothing more
than a syntax trick in a way. And
Actually, for bitfields the types into which the bits are packed are not
left to the compiler. If you said int c : 4, then it will use a int.
If you have:
int a : 24;
int b : 24;
int c : 16;
and int is 32 bits on your platform, then a will be 24 somewhere in 32
bits, same thing for b, and c
In a practical manner, I would say that Go is production ready whilst Rust
still has some way to go (!). Rust 1.0 is approaching, but is not there
yet, and there are still syntax/semantic questions being examined and lots
of work on the runtime... not to mention the lack of libraries (compared to
Intriguing...
I googled a bit to check what this was about and found:
- pseudo-reloc.c, the part of mingw handling pseudo-relocations =
http://www.oschina.net/code/explore/mingw-runtime-3.18-1/pseudo-reloc.c
- the patch for pseudo-reloc v2 support =
Most C/C++ projects require parallel make because they lack modules. I work
on medium-large projects in C++, for which we use Boost as well as about a
hundred custom middleware components. A simple source file of ~1000 lines
ends up generating a preprocessed file in the order of between 100,000
One question:
Do you only want to retrieve the exact type that was passed in, or would
you want to be able to extract an impl that matches the type actually
contained ?
The latter is more difficult to implement (dynamic_cast goes through hoops
to check those things), but it is doable if
Hello,
I cannot comment on the difficulty of implementation, however I can only
join Armin in wishing that if it ever takes off it would be better to make
the declaration explicit rather than having to parse the definition of the
function to suddenly realize that this is not a simple function but
Hi Corey,
It's great to see that people are thinking more and more about integrating
Rust in existing languages!
I wonder however whether the other alternative has been envisioned: if Rust
requires a runtime to work properly (specifically: TLS, task failure),
would it be possible to provide an
Given that all values of u8 are meanginful, there is no space for an extra
bit, so it is no surprise that it cannot be packed.
For pointers, for example, it is typical to exploit the fact that the null
pointer is a meaningless value and thus rely on this sentinel value to
encode the absence of
It could be.
If it is not, it may be that Option needs some love at the CodeGen level to
make it so :)
-- Matthieu.
On Wed, Jul 24, 2013 at 6:46 PM, Corey Richardson co...@octayn.net wrote:
On Wed, Jul 24, 2013 at 12:42 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
Given that all
On Sat, Jul 6, 2013 at 5:26 PM, Tommy M. McGuire mcgu...@crsr.net wrote:
On 07/03/2013 09:53 PM, Ashish Myles wrote:
hello.rs:4:8: 4:33 error: borrowed value does not live long enough
I was just about to write asking about this. I discovered it with the
following code:
for
On Fri, Jul 5, 2013 at 11:07 PM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Jul 5, 2013 at 4:58 PM, Bill Myers bill_my...@outlook.com wrote:
I believe that instead of segmented stacks, the runtime should determine
a
tight upper bound for stack space for the a task's function, and
On Thu, Jul 4, 2013 at 2:26 AM, Graydon Hoare gray...@mozilla.com wrote:
On 13-07-03 05:06 PM, Tim Chevalier wrote:
I don't know of any such proposal already, so I encourage you to take
the lead. Of course, even with the translations in the tree, there's
the risk that they could become
On Thu, Jul 4, 2013 at 9:48 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink bstei...@gmail.com
wrote:
Hi,
On 2013.07.05 02:02:59 +1000, Huon Wilson wrote:
It looks like it's a lot more consistent than the original [IRFY],
so it might
Hello,
Regarding type-erasure without stack-allocation I remember a question on
StackOverflow on how to implement this.
In C++ this can be done using templates = template typename T, size_t
Size, size_t Alignment class Pimpl;
Pimpl will then declare raw storage (char [] in C++03,
Hi,
I was reading with interest the proposal on library-defined garbage
collection (by use of dedicated types), and I have a couple of questions.
My main worry, and thus question, is how to handle cross-scheme cycles ?
There does not seem to be anything preventing me to have a RcObject
reference
On Fri, Jun 7, 2013 at 7:05 AM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
The linked article contrasts them with the GoF-style iterators as well.
The Rust Iterator trait is similar to the one pass ranges
On Sat, Jun 1, 2013 at 3:43 PM, Thad Guidry thadgui...@gmail.com wrote:
I know that Rust currently doesn't currently support this, but what if
futures could use a custom allocator? Then it could work like this:
1. Futures use a custom free-list allocator for performance.
I don't see why
Hi,
I am not quite sure whether you are asking for a multi-cast feature (all
clients receive a copy of the message) or for a send-to-one-among feature
(in which one of the available client would pick up the message).
Could you elaborate ?
-- Matthieu
On Tue, May 28, 2013 at 11:45 AM,
As the error implies, the function type that you try to pass as a callback
is incorrect.
The problem is that because the callback is called from C it ought to be
compatible with C, thus the extern bit.
Rather than defining an anonymous function, you need to write an extern
fn function (with a
On Mon, May 6, 2013 at 12:28 AM, Lindsey Kuper lind...@composition.alwrote:
On Sun, May 5, 2013 at 6:17 PM, Andreas Rossberg rossb...@mpi-sws.org
wrote:
On May 5, 2013, at 23:54 , Lindsey Kuper lind...@composition.al wrote:
On Sun, May 5, 2013 at 4:19 PM, Noam Yorav-Raphael
On Sat, May 4, 2013 at 1:15 PM, Olivier Renaud o.ren...@gmx.fr wrote:
Hi,
2013/5/3 Graydon Hoare gray...@mozilla.com
(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
On Mon, Apr 29, 2013 at 6:33 PM, Jack Moffitt j...@metajack.im wrote:
As was pointed out earlier with Mozilla source code, integer overflows
do not happen. Probably because, in security-conscious code, you are
supposed to validate your inputs for your actual expected range, and
when you
I was thinking about the mapping of / and % and indeed maybe the simplest
option is not to map them.
Of course, having an infix syntax would make things easier: 5 % 3 vs 5 rem
3 vs 5.rem(3), in increasing order of typed keys (and visual noise for the
latter ?).
On the other hand, if there is no
On Thu, Apr 25, 2013 at 6:53 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/25/13 9:23 AM, Felix S. Klock II wrote:
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
On Wed, Apr 17, 2013 at 9:24 AM, Eddy Cizeron eddycize...@gmail.com wrote:
2013/4/16 Brandon Mintern bran...@mintern.net
I agree with you completely, Matthieu, but that's not the kind of thing I
had in mind. Consider a LinkedList implementation. Its nodes and their
pointers would be private
I would also had that before jumping straight to direct access, one should
carefully measure. With inlining and constant propagation I would not be
surprised if the optimizer could not turn an access via the public API into
as efficient code as a direct access to the field in the trait method
Well, a full effect system might not be necessary just for safe plugins.
Since we have a way in Rust to indicate which version a plugin we want to
link to, we could apply some restrictions there.
For example, specifying that only a certain list of other libraries can be
used by this plugin (and
On Sat, Jan 12, 2013 at 3:21 AM, James Gao gaoz...@gmail.com wrote:
and how about these two case:
a) fn fooT1: Ord, Eq, Hash; T2: Ord, ::Eq (...) {...}
b) fn fooT1: Ord + Eq + Hash, T2: Ord + ::Eq (...) {...}
Really likes b), + looks especially suiting since we are adding up
requirements.
On Sun, Oct 28, 2012 at 8:48 PM, Niko Matsakis n...@alum.mit.edu wrote:
Regardless of whether manual memory management is desirable as an end
goal, support for it is essentially required if you wish to permit tasks to
exchange ownership of data without copies. For example, in Servo we have a
On Tue, Oct 23, 2012 at 2:46 PM, Julien Blanc wh...@tgcm.eu wrote:
Lucian Branescu a écrit :
Something like this
http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/
Very nice introduction. The only question that arises for me (coming from
c++ ground and
On Sat, Oct 20, 2012 at 11:16 AM, James Boyden j...@jboy.me wrote:
On Sat, Oct 20, 2012 at 10:48 AM, Graydon Hoare gray...@mozilla.com
wrote:
Some references to the lurking plan here:
https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html
Firstly, I'd like to express my
On Sat, Oct 20, 2012 at 1:37 PM, Gareth Smith
garethdanielsm...@gmail.comwrote:
Option 3 looks prettiest to me, but I like that in Option 1 the
error-raising code comes before the error-handling code (based on
experience with other languages). This might not be an issue in practice.
I am not
On Sat, Aug 4, 2012 at 6:53 PM, Patrick Walton pwal...@mozilla.com wrote:
On 08/02/2012 12:51 PM, Emmanuel Surleau wrote:
Hi,
I'm new to rust, and I'm struggling to find an elegant way to work with
default
parameters.
Generally we've been experimenting with method chaining to achieve
On Sat, Jun 2, 2012 at 9:12 PM, Niko Matsakis n...@alum.mit.edu wrote:
Hello Rusters,
I want to remove bind. It's a pain to maintain and a significant
complication in the language semantics (both problems caused by having two
kinds of closures with subtle distinctions). Nobody really
On Fri, May 25, 2012 at 7:16 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
On Fri May 25 18:01:25 2012, Patrick Walton wrote:
On 05/25/2012 08:43 AM, Kevin Cantu wrote:
This conversation reminds me of Alexandrescu's talk about D's scope
keyword:
On Wed, May 23, 2012 at 2:47 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Actually, one of the conclusions of our previous discussion is that
Java/C++/ML-style exceptions are probably not what we want for Rust. I
seem to remember that we also concluded that using failures as
On Tue, May 1, 2012 at 5:51 PM, Sebastian Sylvan sebastian.syl...@gmail.com
wrote:
On Tue, May 1, 2012 at 4:07 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
As a consequence, I am unsure of the impact this article should have on
Rust's GC design. The implementation strategies
Hi Sebastian,
I have a few comments.
On Sun, Apr 29, 2012 at 12:21 AM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
On Fri, Apr 27, 2012 at 3:15 PM, Niko Matsakis n...@alum.mit.edu wrote:
The types `[]T` and `str` would represent vectors and strings,
respectively. These types have
On Sat, Apr 28, 2012 at 8:12 AM, Marijn Haverbeke mari...@gmail.com wrote:
I must say I prefer Graydon's syntax. `[]T` sets off all kinds of
alarms in my head.
I have no strong opinion on dynamically-sized types. Not having them
is definitely a win in terms of compiler complexity, but yes,
On Tue, Apr 24, 2012 at 11:24 PM, Graydon Hoare gray...@mozilla.com wrote:
On 12-04-24 11:30 AM, Matthieu Monrocq wrote:
However this is at the condition of considering strings as list of
codepoints, and not list of bytes. List of bytes are useful in encoding
and decoding operations
Hello,
As this is going to be my first e-mail on this list, please do not hesitate
to correct me if I speak out of turn.
Also do note that I am not a native English speaker, I still promise to do
my best and I will gladly welcome any correction.
First, I agree that operations on vectors
94 matches
Mail list logo
