Wow, I thought this mailing list died a long time ago. Try
https://users.rust-lang.org/ or Stack Overflow for this type of
question, or just look for examples.
#ifdef is definitely not Rust. Your other example is fine.
On Mon, 2019-08-12 at 15:44 -0400, Matt Zand wrote:
> I am working on
Shouldn't the compiler automatically put large arrays on the heap? I thought
this was a common
thing to do beyond a certain memory size.
On Thursday 27 November 2014 04:28:03 Steven Fackler wrote:
The `nums` array is allocated on the stack and is 8 MB (assuming you're on a 64
bit platform).
It was the nesting else cases that got me. See
https://github.com/dhardy/rfcs/blob/master/active/-with-else.md for some
more examples (slightly different syntax). The equivalent with match is ugly
and I suspect closures would be no better.
On Tuesday 14 October 2014 09:05:56 Steven Fackler
Dear Rust users,
I heard Nick Cameron gave a talk about Dynamically Sized Types in London last
Thursday[1]. Are there recordings available?
[1]: http://www.meetup.com/Rust-London-User-Group/events/196222722/
___
Rust-dev mailing list
Which is why I don't use it.
A third point is that root access is really not required; e.g. I usually
install software into /home/install/NAME and then do no more than create links
to the binaries from my own bin folder.
Of course, that doesn't remove the need to validate the downloaded files.
I like the mailing list for news items: new releases, This Week in Rust, RFCs
for discussion, etc. Maybe replace it with a news-only list where all posts
are moderated?
This is one thing both discourse and RFCs don't seem to be good at: summarised
news (e.g. notifications on new
Any chance you can add RSS feeds on the new blog?
On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote:
Been super busy, but there's some good stuff in store:
http://blog.octayn.net/blog/2014/06/09/future-of-twir/
On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski ntypan...@gmail.com
wrote:
Using Go (or Python or whatever) for this implies either the build system needs
to include compiled
binaries (not good) or the system doing the build needs to have a Go (or xyz)
interpreter installed. So
cross-platform build configurations will require an external dependency (or
writing
As far as I am aware, using theorem proving tools[1] to provide limits on value
ranges is pretty
hard and often computationally intensive to do in /simple/ code. I've only seen
prototype systems
where the user is expected to write full contracts on exactly how every
function may modify
every
As far as I am aware, using theorem proving tools[1] to provide limits on value
ranges is pretty
hard and often computationally intensive to do in /simple/ code. I've only seen
prototype systems
where the user is expected to write full contracts on exactly how every
function may modify
every
Just adding doc for common cases is enough in my opinion. If you add StringMap
you've got four
possible variants (map/set and tree/hash); even without that another class
just to rename a few
methods.
Diggory
On Friday 06 Jun 2014 08:44:12 Patrick Walton wrote:
On 6/6/14 6:40 AM, Diggory
of the inserted strings
are
sufficient).
Regards,
Diggory Hardy
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
later
today.
On 2014-06-06 9:40 AM, Diggory Hardy li...@dhardy.name wrote:
Dear List,
I want to use strings as map keys, but couldn't find any mention of this
in my understanding common use-case. The following works but as far as I
understand requires a copy of the potential key
There is static analysis (i.e. determine ahead of time exactly what values
variables may take), but it's certainly not a panacea: the analysis step is
slow (probably too slow to fully integrate into a compiler), not everything
can be solved, and most existing solvers are not free software as
A further point in favour of CMake is that it would make multi-language
projects easier to manage, in particular transitioning a C-family project to
Rust.
On Friday 10 January 2014 08:34:32 Lee Braiden wrote:
On 10/01/14 08:16, Gaetan wrote:
I am not in favor of a customized build system.
Three jobs, three key words:
1) creating structure: `mod foo { ... }` is used to organise code into modules
2) external references: `extern mod foo` imports foo, but without any name
binding (e.g. Java and Python's import statements also bind names)
3) creating aliases/binding names: `use
On Wednesday 11 December 2013 17:27:43 John Mija wrote:
Sounds good me.
I believed that the API would be frozen in 1.0 like Go. Besides, that
version is going to attract many developers and without a generic API to
build SQL drivers, it would be very chaotic to have different clients of
SQL
In reply to Nicholas Matsakis's post:
http://smallcultfollowing.com/babysteps/blog/2013/11/14/treating-vectors-like-any-other-container/
That's a really nice write-up Nicholas. I wanted to chip in because I had a
think about some similar issues in the past, but your review is far more
thorough
If tree is ordered, e.g. lexically, it might. I've certainly found
std::map...::lower_bound useful in the past:
http://en.cppreference.com/w/cpp/container/map/lower_bound
On Friday 15 November 2013 15:52:02 Oren Ben-Kiki wrote:
Slice traits weren't: though, does `tree.mut_slice_between(foo,
My opinion is that clear semantics and good documentation is much more
important than familiar syntax. Besides, it's not too closely C++ syntax; for
example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s
`T x = v`. (This is a good choice, as anyone who know's why C++ has a
Thanks for the clarification. The current design actually makes sense to me
after re-reading about dynamically sized types.
On Friday 08 November 2013 09:29:37 Patrick Walton wrote:
On 11/8/13 7:47 AM, Diggory Hardy wrote:
What's wrong with sticking with convention here? E.g. C++'s `string
On Friday 08 November 2013 06:33:23 Niko Matsakis wrote:
I am not sure why Daniel says that a `~str` or `~[]` is not an owned
box. I guess he's using the term in some specific way. I consider
`~str` and `~[]` to be exactly the same as any other `~T` value in
usage and semantics. They are
Well, your program needs to handle the error somehow if there is one.
Something like this could work (though syntax may be wrong):
let file = match io::result(|| File::open(Path::new(/some/path)) {
Ok(f) = f /* i.e. file is set to f */
Err(e) = fail!(cannot open file)
}
Alternatively
use std::rt::io::File;
let mut stream = File::create(test.txt);
writeln!(mut stream, test {}, {}, {aa}, 1, 3.0, aa=2);
Which I think looks a lot better than before! I would love to not have
to write `mut stream` or have something like `stream.write!(foo, bar,
baz)`, but I
On Sunday 29 September 2013 12:26:05 Callme Whatiwant wrote:
On Tue, Sep 10, 2013 at 12:39 AM, Marijn Haverbeke mari...@gmail.com
wrote:
The Rust team is aware of this possibility, and is guarding against it
by keeping a log of checksums and source git revisions for the various
versions of
Hi,
On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:
On 9/25/13 6:32 AM, Alexander Sun wrote:
Multiple return values
if has a function like this:
fn addsub(x : int, y : int) - (int, int) {
return (x+y,x-y);
}
them, this is valid:
let (b,c) =
Hello,
Did anything ever happen about this? Sorry, I stopped reading the mailing list
a while back...
I'd be interested, if not very much involved with Rust at the moment. (I live
in Basel.)
Cheers
On Sunday 04 August 2013 13:23:33 Jordi Boggiano wrote:
Heya,
I know this is a long shot
I'm voicing my support for the nice docstring comments :).
I'd be all for only having // comments and /// docstrings though, but
I have a feeling a lot of people would strongly disagree.
___
Use /// to start a doc-string and / to continue one.
On Friday 26 April 2013 20:33:36 Graydon Hoare wrote:
On 26/04/2013 6:47 PM, Huon Wilson wrote:
I'm proposing creating std::rand with these, possibly with a few extra
traits e.g. RandomDistribution. For reference the C++ stdlib
contains a whole pile of distributions
What the...
There's better things to innovate on than renaming 'continue'. Sometimes I
think rules get taken too far. Perhaps the fact this has been such a long-
running argument is evidence of a problem.
On Friday 26 April 2013 10:16:15 Graydon Hoare wrote:
On 26/04/2013 8:24 AM, Felix S.
My opinion (that nobody will follow, but I still give it) is that integers
should not have the / operator at all. This was one of the bad choices of
C (or maybe of a previous language).
Hmm, maybe, though I can imagine plenty of people being surprised at that.
What really gets me though is
Please don't use HTML when posting to lists.
2) function parameter types or return type that are not type parameters have
all the same implicit lifetime by default, but they can be qualified
explicitly with some lifetime.
That would mean that a function with default-lifetime parameters taking
Hello list (new here),
May I comment on a post from this Monday?
Heri Sim posted:
1st, dereferencing should be automatic everywhere.
Running a pattern match on borrowed boxes should NOT require an asterisk
(*).
Passing in a stack-local variable to a function or closure (that
requires
33 matches
Mail list logo
