Hello,
New to Rust. Is there (already) a list for mutual help in the usage of Rust? If
not, I guess it may be worth having one, distinct from the dev list, even if the
language is a moving target, even for people who rather intend, at terms, to
participate in the development. It is in fact
On 11/05/2013 06:17 PM, Patrick Walton wrote:
On 11/5/13 2:44 AM, spir wrote:
That you very much for this complete answer, Patrick. Things are clearer.
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
syntactic
schema (and could not find any example in any doc online). I'm blocked, stupidly.
spir@ospir:~$ rust -v
rust 0.8
host: x86_64-unknown-linux-gnu
Also, I have a general problem with writing struct instances with the type
apart; meaning, without any type param, I get
On 11/08/2013 05:47 PM, Igor Bukanov wrote:
C++'s `string` and `vectorT` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose
On 11/08/2013 09:43 AM, Gaetan wrote:
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: OptionUserInfo,
host: ~str,
port: Option~str,
path: ~str,
query: Query,
fragment: Option~str
}
pub type Query =
On 11/08/2013 09:53 AM, Daniel Micay wrote:
It couldn't be called `str`, because `str` is a slice.
Why couldn't str be slices? (eg somewhat like arrays are slices in D)
Also, i don't understand literals in Rust currently. Same for static arrays.
Denis
.)
Please read the blog posts on dynamically sized types.
All right, I'll do.
PS: Except I cannot find them.
Don't seem listed in the list of blog post at
https://github.com/mozilla/rust/wiki/Docs
Also not in the archives of your own blog at:
http://pcwalton.github.io/blog/archives/
Denis
spir
On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel
Micay danielmi...@gmail.com wrote:
On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote:
On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote:
I know that many people don't like the
On 11/09/2013 08:36 PM, Niko Matsakis wrote:
See my other e-mail about choosing a representation for `*T`. I am
currently thinking that the representation of `~T`, `T`, and `*T`
should be the same for all `T`. I think this addresses a number of
issues and opens up new capabilities, though it
Hello,
Well, I wonder if we could exchange those formats. Here is how they work:
fn main () {
struct P {i:uint, j:uint};
let (b, u, i, x, c, s, a, p) =
(false, 1u, -1, -1.11, 'c', abc, [1,2,3], P{i:1,j:2});
let z : Optionuint = None;
// Poly
println!({:?} {:?} {:?}
Hello,
I am searching for the easy or standard way to return an item from a collection.
Here is a fictional example showing the issue:
struct CollItem {
items : ~[Item]
}
implItem CollItem {
fn first (self) - Item {
// this line is for comments below:
let it =
On 11/11/2013 01:18 PM, Daniel Micay wrote:
The reflection-based `{:?}` doesn't follow the privacy rules, so it will
never be a format with a stable output. The low-level implementation
details of a type aren't a sensible format for any application to be using.
Provided it goes on doing the
On 11/11/2013 02:47 PM, Felix Klock wrote:
Denis (cc'ing rust-dev)-
Thank you very much, Felix, for this clear and exhaustive reply.
How does it then interpret the line:
let it = self.items[0];
The only way to make sense of that is to copy, isn't it? What else?
An assignment
On 11/11/2013 09:46 PM, Corey Richardson wrote:
I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).
I don't think Rust can succeed as a language if it massively resembles
the language it intends to offset (C++).
Denis
On 11/11/2013 09:16 PM, Oren Ben-Kiki wrote:
At any rate, I'm not claiming this is necessarily the best approach for
Rust; I'm just wondering, what is the proposed way to address this use
case? None of the manual approaches seems very appealing (unless there's a
better one I missed).
My
Hello Rust people,
A data structure holds (unpointed) cells in an array. Then, a number of linked
lists part of the data structure link to those same cells. What is the right
Rust way to do that? I cannot have the language accept the instruction
establishing a link, whatever kind of pointer I
Hello,
The ref manual speaks of copying pointers
[http://static.rust-lang.org/doc/0.8/rust.html#pointer-types]:
Managed pointers (@)
These point to managed heap allocations (or boxes) in the task-local,
managed heap. Managed pointers are written @content, for example @int means a
PS: What would be, in fact, the rusty way for a simplissim linked list. I use
Option~Cell for now, to have something clean (None) to end the list, since
Rust looks rather functional. But as always with Option this way quite obscures
and complicates the code (Some() expressions, match
Hello,
I have an error cannot assign to immutable field. However, it is mutable as I
understand according to inherited mutability rule exposed in the tutorial
(section 'Structs'). The field in question is in a struct itself item of an
array, itself field in a super-structure (lol!) which is
On 11/13/2013 02:06 PM, Huon Wilson wrote:
On 13/11/13 23:55, spir wrote:
Hello,
I have an error cannot assign to immutable field. [...]
You need to use the .mut_iter() method, [T].iter() yields T references, while
the former yields mut T references (and can only be used on vectors that have
I completely share your views, Daniel.
[Would have expressed them myself if I did not know (from experience) that
constructive critics by me (in english) usually are mistaken or misunderstood:
people just deny, argue, or reply violently. But you do a good job, here, in my
opinion.]
Denis
Could there be a kind of rust-tutorial-in-progress wiki page? (with required
subscription to edit). Seems to me the easiest path to cooperative edition.
Then, just have a single person responsible for regularly pushing the 'in
progress' version as the 'offical' one, whenever its state is ok.
These are 2 points of secondary importance (or even less).
What about the following pattern:
for x:Type in expr {
// proceed with x
}
as equivalent to:
for y in expr {
let x = y as Type;
// proceed with x
}
both for iterator loops and range loops?
I'm exploring the tutorial Rust for Rubyists at
[http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for
rubyists, as stated in the introduction. Looks pretty good to me (just my
opinion), should definitely be pointed to from the Rust Docs page at
On 11/15/2013 01:27 PM, spir wrote:
[...]
Thank you Huon Daniel, your replies answer my needs. I supported the issue
about removal of signed `int` as default (BAD! ;-).
Actually like `for i in range(1u, 9u)` as an alternative for `for i:uint in
range(1 ,9)`, but there also, there should
On 11/15/2013 03:55 PM, Marijn Haverbeke wrote:
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people haphazardly updated stuff here and
there, but the bulk of it still looks
On 11/15/2013 05:52 AM, Patrick Walton wrote:
* One of the BIG problems with D uptake is the split library problem
referred to before. They could not get a comfortable standard library
for a long time, despite some extremely bright and decently famous
engineers working on D. My understanding is
Hello,
say a function defines 4 pointed elements of data. Depending on logical
conditions, one of them escapes the func to be assigned to some world variable
(static or on heap), while another is returned. How does Rust determine which of
those data are to be freed? Seems this can only be
On 11/19/2013 12:09 PM, Daniel Micay wrote:
The `loop` keyword still exists for the moment, but only for infinite
loops. I'd prefer removing it and just using `while true { ... }`.
My view on conditionned loop is something like:
loop [while cond] {
...
[continue if cond]
...
On 11/19/2013 10:12 AM, Jordi Boggiano wrote:
Often there is an alternative
to pooping sigils all over the code, but if you don't understand the
concepts behind it it's hard to reason about what those alternatives
could be.
+++
This is what I'm asking for about pointer variety and memory
On 11/19/2013 10:51 AM, Gaetan wrote:
In the french presentation for rust 0.8 [1], the author gives the analogy
with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptrT
- borrowed pointer works like C++ reference
and I think it was very helpful to better understand them. I
On 11/19/2013 12:51 PM, Daniel Micay wrote:
So in your opinion, what's wrong with the `Boxes` section?
http://static.rust-lang.org/doc/master/tutorial.html#boxes
I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case
On 11/20/2013 04:03 AM, Val Markovic wrote:
Fair point. I give you guys a lot of credit though, Rust is a wonderful
language in general. I also admire how willing core Rust devs are to admit
ok that was a bad idea, let's try something else. I don't see that every
day; Rust is better for it.
On 11/20/2013 02:51 PM, Bill Myers wrote:
Have you considered making deref the default instead and requiring moves to use an
explicit move keyword?
Basically, from this hypothetical syntax to current one:
- x = x
- mut x = mut x
- move x = x
One could even make the implicit in parameter
On 11/22/2013 07:01 AM, Tommi wrote:
Now, off-topic: I've been trying to post the following question to this mailing
list for like 4 times, but no dice. I seem to have better luck when replying to
posts, so here it goes:
struct Value {
n: int
}
impl Value {
fn squared(mut self) -
On 11/26/2013 10:03 AM, Brandon Sanderson wrote:
I'd definitely be in support of the change to easy tagging - I've seen
quute a few issues where I've thought 'I could do this' but then realized I
have no idea where to start.
On 2013-11-26 12:59 AM, Corey Richardson co...@octayn.net wrote:
Same
On 11/30/2013 08:10 AM, Kevin Ballard wrote:
As I said in the IRC channel, the reason why users often don't realize that
`~T` is allocation, is not a failure of syntax, but a failure of documentation.
The only reason why a user would know that `new Foo` allocates is because
they've been
On 11/30/2013 11:24 AM, György Andrasek wrote:
On 11/30/2013 09:34 AM, Patrick Walton wrote:
IMHO sigils made sense back when there were a couple of ways to allocate
that were built into the language and there was no facility for custom
smart pointers. Now that we have moved all that stuff into
On 12/02/2013 11:12 AM, jeti...@web.de wrote:
Hello,
I lately had a look at Rust and really liked it in many ways. Rust has really
everything I'm missing in Go ;-). There is something about traits I would like
to ask I can't see from the manual. Question is whether you define instance
variables
On 12/02/2013 09:43 AM, Eric Reed wrote:
I think the 'new(place) expr' or 'box(place) expr' is pretty confusing
syntax. To me, it's not at all clear that new(varA) varB means eval varB
and put it into varA instead of eval varA and put it into varB.
I'd much prefer syntax that makes it very clear
On 12/02/2013 11:57 AM, Kevin Ballard wrote:
With @ going away another possibility is to leave ~ as the normal allocation
operator and to use @ as the placement operator. So ~expr stays the same and
placement looks either like `@place expr` or `expr@place`
I like that, with expr@place. Does
On 12/02/2013 07:15 PM, Kevin Ballard wrote:
Personally, I’ve never met a forum that I cared for. Mailing lists are nice.
I second the idea of a rust-users ML.
Same for me.
denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 12/03/2013 09:41 PM, Martin DeMello wrote:
On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry thadgui...@gmail.com wrote:
Users benefit from the developers list and vice-versa... splitting us
apart would not be a wise choice.
the only downside is that people are reluctant to ask newbie user
On 12/03/2013 11:01 PM, Martin DeMello wrote:
keeping up with email is a lot easier than pretty much everything else,
though. the solution to keeping old messages around is mirroring the
mailing list to a searchable archive, not moving to a forum en masse and
sacrificing ease-of-conversation for
On 12/06/2013 09:41 PM, Simon Sapin wrote:
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we assume the input is valid and
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result or
option.
This provides the important semantic information (that I've evoked at the end
end of a long earlier
On 12/07/2013 01:55 AM, Simon Sapin wrote:
On 07/12/2013 00:49, spir wrote:
About the latter, in particular it should be obvious in code, without knowledge
of language arcanes or weird idioms, that (or whether) the caller expects a
success unconditionally -- because (and in other words
On 12/07/2013 10:53 AM, Simon Sapin wrote:
On 07/12/2013 01:07, spir wrote:
Maybe it's only me, but this not at at all clear to my eyes. My imagined soluton
(for a totally different lang) was something like this, on the caller side:
ucodes = s.utf8_decode()!// source should be correct
On 12/07/2013 02:08 AM, Jordi Boggiano wrote:
On Sat, Dec 7, 2013 at 2:01 AM, spir denis.s...@gmail.com wrote:
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result
On 12/07/2013 12:57 PM, Devin Jeanpierre wrote:
On Sat, Dec 7, 2013 at 3:33 AM, spir denis.s...@gmail.com wrote:
But the issue exists anyway... dunno about solution. In fact we'd ned to
invert the logic: instead of:
x = foo() // Option element wrapping possible result
On 12/09/2013 04:53 PM, Damien Radtke wrote:
I have no idea if it would be feasible in the standard library, but
wouldn't the ideal solution be having one function (e.g. from_utf8()) that
could return two possible values, a bare result and an Option? Letting the
compiler decide which version to
On 12/11/2013 06:04 PM, Patrick Walton wrote:
We aren't likely to block 1.0 on this. Instead of stabilizing all libraries once
and for all in 1.0 like Go did, we're taking a gradual approach to libraries
similar to that of node.js, in which 1.0 will have some library modules stable
and some
On 12/13/2013 11:43 AM, Diggory Hardy wrote:
What would you do?
Have no structure (no mod)? Or automatically create it from the file structure?
I think this is a good possibility, make the module/crate organisation mirror
the filesystem (or the opposite):
* 1 module = 1 file of code
* 1
On 12/14/2013 05:28 AM, Liigo Zhuang wrote:
There is an official tool called rustpkg, and there is a attribute call
pkgid, so you cann't just easily saying there is no package in rust. If
no package, why not using rustcrate and crateid for consistency? (I do
not think 'crate' is a good name,
On 12/30/2013 05:29 PM, Patrick Walton wrote:
In general I understand the concern, but there are also a huge number of people
who just want the language to stabilize so that they can use it in production.
The window for relevance is finite and we've been designing the language for a
*long* time
On 12/30/2013 02:00 PM, Armin Ronacher wrote:
Hi,
I am not using Rust nearly as much as I wish I could, but I absolutely love
playing around with it and seeing where it's heading. I think all things
considered the language is going exactly where I want it to go. It's for the
most part very
On 12/31/2013 08:06 AM, Carter Schonwald wrote:
as a counter point, in strongly typed languages (of which rust is one), the
type checker is a great aid in fixing breaking changes :). In fact it makes
addressing such breakages quite easy.
This is pretty notable in other strongly typed langs like
On 12/31/2013 01:43 PM, Till Schneidereit wrote:
Without responding to everything in your message, two quick points:
For being written by someone afraid 'of the terrible level of violence, in
[your] view, present in the programming community', your message is
awfully condecending and dismissive
58 matches
Mail list logo
