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 Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton pcwal...@mozilla.com wrote:
I've observed a lot of beginning Rust programmers treat the language as add
sigils until it works. (I have specific examples but don't want to name
people here; however, feel free to contact me privately if you're
Is there any specific issue with the current tutorial section on
boxes? It mentions every case where owned boxes are useful.
http://static.rust-lang.org/doc/master/tutorial.html#boxes
I keep hearing that it should be better, but have yet to see any hints
on where it falls short. It's not going
I don't think there is any particular issue with the tutorial, but we need
more recipes on how to handle typical situations.
-
Gaetan
2013/11/19 Daniel Micay danielmi...@gmail.com
Is there any specific issue with the current tutorial section on
boxes? It mentions every case where
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 don't know if
it is true or now, but
On 19/11/13 20:51, 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 Tue, Nov 19, 2013 at 4:51 AM, Gaetan gae...@xeberon.net 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
In case this helps, I recently noticed that the sigils correspond to
possessive pronouns:
'~' = my,
'' = their,
'@' = our
Of course, `@` might be going away, but `Rc`, `Gc`, and so forth all
(will) have the same intuitive content, only different representations
(among other
Can I advise to have a certain constitency in the semantics?
Not having ~foo, *foo, Rc, Gc.
I would rather prefere having
~foo *foo foo @foo
of
Somethingfoo, otherfoo, Rc foo
By the way, I like pretty much your pronoums thing, this help understanding
:)
-
Gaetan
2013/11/19 Gábor
On Tue, Nov 19, 2013 at 5:56 AM, Gaetan gae...@xeberon.net wrote:
Can I advise to have a certain constitency in the semantics?
Not having ~foo, *foo, Rc, Gc.
I would rather prefere having
~foo *foo foo @foo
of
Somethingfoo, otherfoo, Rc foo
By the way, I like pretty much your
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 Tue, Nov 19, 2013 at 6:45 AM, spir denis.s...@gmail.com wrote:
This helped me too, even if I'm not a C++ programmer (can only read).
However, it is still not enough to understand the meaning of each of those
pointer varieties, imo (at least, _i_ still don't get it). What semantic
kinds of
+1 semantics is so important
Le 19 nov. 2013 12:22, spir denis.s...@gmail.com a écrit :
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
On 19/11/13 05:17, Patrick Walton wrote:
I've observed a lot of beginning Rust programmers treat the language as
add sigils until it works. (I have specific examples but don't want to
name people here; however, feel free to contact me privately if you're
curious.) They end up with slow
The most common use case for owned boxes is creating recursive data
structures like a binary search tree.
I don't think this is the most common use of owned boxes: string
management, ...
I don't think it a good idea to place binary search tree in a tutorial.
You don't do this every day :)
-
On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote:
The most common use case for owned boxes is creating recursive data
structures like a binary search tree.
I don't think this is the most common use of owned boxes: string management,
...
I don't think it a good idea to place
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
I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere to make the compiler happy.
~str should be a ~T. If it is not, it should use another semantic.
However, I don't see
On Tue, Nov 19, 2013 at 7:35 AM, spir denis.s...@gmail.com wrote:
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of
On Tue, Nov 19, 2013 at 7:40 AM, Gaetan gae...@xeberon.net wrote:
I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere to make the compiler happy.
~str should be a
I think it is one of the first thing to explain, actually...
Playing with strings, using the method in std or extra requires to
understand it. I wanted to use (and improve) extra::url and others (like
std::path,...) and... I was simply lost with all of these ~str... and
nothing in the manual or
On Tue, Nov 19, 2013 at 7:52 AM, Gaetan gae...@xeberon.net wrote:
I think it is one of the first thing to explain, actually...
Playing with strings, using the method in std or extra requires to
understand it. I wanted to use (and improve) extra::url and others (like
std::path,...) and... I
Sorry, but it's not clear.
the only occurences of ~str are in Declaring and implementing traits
section...
Maybe by adding more string specific examples would help...
And a special section one why ~str is not a ~T would be so useful!
-
Gaetan
2013/11/19 Daniel Micay danielmi...@gmail.com
However, I want to highlight it is really appreciable that you, the rust
team, are so open to our question.
Just wanted to give you this feedback, I don't want to be held like the guy
who criticize the current work, I know very much that is could be very
annoying.
Just willing to help :)
-
On Nov 19, 2013, at 3:08 AM, Daniel Micay danielmi...@gmail.com wrote:
I wouldn't mind not having `~T` in the language at all, but am not
really opposed to including it because there's no harm. Choosing to
special-case arbitrary non-trivial data structures like vectors and
reference counted
+1
在 2013年11月19日 下午8:27，Gaetan gae...@xeberon.net写道：
The most common use case for owned boxes is creating recursive data
structures like a binary search tree.
I don't think this is the most common use of owned boxes: string
management, ...
I don't think it a good idea to place binary
在 2013年11月19日 下午8:35，spir denis.s...@gmail.com写道：
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
在 2013年11月19日 下午8:41，Gaetan gae...@xeberon.net写道：
I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere to make the compiler happy.
~str should be a ~T. If it is not,
在 2013年11月19日 下午8:44，Daniel Micay danielmi...@gmail.com写道：
On Tue, Nov 19, 2013 at 7:35 AM, spir denis.s...@gmail.com wrote:
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok
on
this point. But
On Tue, Nov 19, 2013 at 4:43 AM, Daniel Micay danielmi...@gmail.com wrote:
The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).
The ~str and ~[T]
On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton pcwal...@mozilla.comwrote:
I agree that we should change this, but give us some credit: it's only an
obvious design mistake now that we've gotten to this point.
[...]
The current status is the product of the slow evolution of a design that
He said IMHO ..
An explicit new is a huge indicator of what is going on ... most people
are familiar enough with stack allocation early adopters are not 9-5
developers..
Ben
On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard ke...@sb.org wrote:
Is that really why, or are you just guessing? I'm
On 11/18/13 7:41 PM, Kevin Ballard wrote:
Is that really why, or are you just guessing? I'm assuming the real
reason is that people are used to languages where heap allocation is
common and stack allocation rare or nonexistant, and don't understand
why boxing everything is a bad idea. In other
The name itself is standard, like it is the default settings...
Le 12 nov. 2013 02:35, Steven Fackler sfack...@gmail.com a écrit :
base64.rs:
let s = [52, 53, 54].to_base64(STANDARD);
= why adding the standard argument? One will ALWAYS want the
STANDARD method of creating the base64
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
Does anyone have empirical data (or even anecdotes) about whether or not
C++ hackers find Rust's syntax appealing? :-)
On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote:
On 11/11/2013 09:46 PM, Corey Richardson wrote:
I don't think Rust can succeed as a language if it
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
More concretely, a good ide with completion, the right snippets and
contextual help is very helpful for learning new language.
I thing this could be a good idea to have an official set of snippets,
typical every day codes, that can be used to create a common contextual
helps for editors (vim,
Hi, Greg --
At this state in Rust's development, we are unlikely to make any major
changes to Rust's syntax. Literally years of effort have gone into
desgining the syntax, and at this point in the language's development,
our focus is on making any non-backwards-compatible changes in
preparation
On Mon, Nov 11, 2013 at 12:27 PM, Greg g...@kinostudios.com wrote:
Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere,
I'm very happy with the safety improvements that Rust brings.
This is true innovation.
At the same time, I am disappointed and quite concerned about Rust's
At this state in Rust's development, we are unlikely to make any major
changes to Rust's syntax.
*cries*
I encourage you to check out Rust's syntax extension / macro system:
http://static.rust-lang.org/doc/master/tutorial-macros.html
*clicks link*
O_O
*cries more*
:'-(
I'm not sure
On Mon, Nov 11, 2013 at 3:41 PM, Greg g...@kinostudios.com wrote:
At this state in Rust's development, we are unlikely to make any major
changes to Rust's syntax.
*cries*
I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset
I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).
Yes, I agree, and that's why I wrote:
By this point, I'm aware that this is unlikely to happen.
I think it's still possible to simplify Rust's existing syntax
Hi,
I am just a lurker as well, so take all of this with a good dose of salt...
At the same time, I am disappointed and quite concerned about Rust's
unimaginative syntax.
It seems to preserve decades of poor decision-making from C++.
Personally, I find it very pleasant. There are a few
From the outside looking in...
I do not see anything preventing Greg from producing many macros or an
entire syntax sub-system to emulate and empower him with any sugary
languages that he might prefer or desire. It is just going to be quite a
bit of work for him, but he could do it himself, if
On Nov 11, 2013, at 1:07 PM, Greg wrote:
I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).
Yes, I agree, and that's why I wrote:
By this point, I'm aware that this is unlikely to happen.
...
However,
Can we have Two rust?
The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...
The second one would include all advanced feature we actually don t
need everyday.
Of course, we don t want to split the language,
Thanks John, for the friendly email. :-)
The choice of the Rust team to adopt a C++-like syntax was very deliberate,
and I'm confident that the members of this team still believe that was the
right choice.
I wonder, right for what reason? Do they actually *like* it? I wrote a lot of
code
On Mon, Nov 11, 2013 at 3:52 PM, Gaetan gae...@xeberon.net wrote:
Can we have Two rust?
The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...
The second one would include all advanced feature we actually
On Mon, Nov 11, 2013 at 6:52 PM, Gaetan gae...@xeberon.net wrote:
For instance url.rs. To parse a string, you have to write this:
let u = url::from_str(urlstring).unwrap();
I would propose this solution:
let u = parse_url(urlstring);
= simpler, easier to read, easier to remember !
Of
Mod hat: This thread has become pretty off-topic. Let's wind it down
and move any specific questions or concrete proposals regarding Rust
to a new, separate thread.
Please familiarize yourself with the Conduct section of
https://github.com/mozilla/rust/wiki/Note-development-policy ,
particularly
On Nov 11, 2013, at 7:05 PM, Tim Chevalier catamorph...@gmail.com wrote:
Also, please avoid
suggesting that people who do or don't like a particular syntax
haven't expanded their mind; it's okay for different people to have
different opinions about language design, and choosing any one
On 11/12/13 9:00 AM, Greg wrote:
Thanks John, for the friendly email. :-)
The choice of the Rust team to adopt a C++-like syntax was very
deliberate, and I'm confident that the members of this team still
believe that was the right choice.
I wonder, right for what reason? Do they actually
On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote:
If you had the energy to build an alternate front-end using a parenthesized
syntax, I'm sure there are others that would give it a try. Me, for instance!
It would be nice if we could:
- A: desugar Rust into a small
base64.rs:
let s = [52, 53, 54].to_base64(STANDARD);
= why adding the standard argument? One will ALWAYS want the
STANDARD method of creating the base64 representation of some bytes, why
not adding this argument as default.
That is not true. If you are going to be putting the Base64
56 matches
Mail list logo
