I found this
posthttp://smallcultfollowing.com/babysteps/blog/2012/10/01/moves-based-on-type/by
Niko, and it seems that at the time everyone agreed that implicit
moving
actually makes things more clear. Why is this different now, only a year
later? :-)
Ok, but serieosly, I allow that this is
On 20 November 2013 02:07, Ziad Hatahet hata...@gmail.com wrote:
Personally I would prefer if in Rust worked similar to const T in c++
In that case, you would not be able to tell whether a function argument was
passed by value or by reference. I actually like this feature about Rust (C#
has
Hello
I'd like to know if you think it could be feasible to have a Python-like
syntax for indices in array and vector?
I find it so obvious and practical.
let i = ~[1, 2, 3, 4, 5]
i[1] returns a the second item (2)
i[1:] returns ~[2, 3, 4, 5]
i[:-2] return ~[1, 2, 3, 4]
i[-2] returns ~[4, 5]
On 20/11/13 21:03, Gaetan wrote:
Hello
I'd like to know if you think it could be feasible to have a
Python-like syntax for indices in array and vector?
I find it so obvious and practical.
let i = ~[1, 2, 3, 4, 5]
i[1] returns a the second item (2)
i[1:] returns ~[2, 3, 4, 5]
i[:-2] return
On 2013-11-20, at 11:16 , Gaetan gae...@xeberon.net wrote:
actually that was what I was expected, sorry I'm not very confortable with
slices yet.
It should not allocate, indeed, there is no reason. Python doesn’t allocate
but the way it handle items, it doesn’t really behave like rust's
Hum that would prevent the step != 1 (allowed in python, but i never used
it)
Le 20 nov. 2013 11:59, Masklinn maskl...@masklinn.net a écrit :
On 2013-11-20, at 11:16 , Gaetan gae...@xeberon.net wrote:
actually that was what I was expected, sorry I'm not very confortable
with slices yet.
It
On Wed, Nov 20, 2013 at 12:30:59AM -0800, Vadim wrote:
I found this
posthttp://smallcultfollowing.com/babysteps/blog/2012/10/01/moves-based-on-type/by
Niko, and it seems that at the time everyone agreed that implicit
moving
actually makes things more clear. Why is this different now, only
First, I am speaking for myself and not my employer.
The current proposal is to remove all autoref except for function
invocations and indexing operations. The method of creating T from ~T
would be `let foo: T = foo` or `*foo`. Vectors and strings can't
currently benefit from the `*foo`
I'am still testing the json lib and I try to encode the json using
extra::json::Encoder. The code I use is :
let mut encoder = extra::json::Encoder(m as @mut Writer);
test.encode(mut encoder);
let st:~[u8] = m.inner();
I have the error : error: cannot move out of dereference of @
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.
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 types in function declarations
unless the move
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
Selon Philippe Delrieu philippe.delr...@free.fr:
Thanks you it works in my simple test but I have this error when I add
it in my program : error: can't find crate for `std`
I try to find why it doesn't work in my program and I found the error
occurs when I add the extern mod zmq;.
Perhaps I
On 11/19/13 9:42 PM, Tommi wrote:
Our problem is that, given let arg: ~A;, seeing only foo(arg) in code
doesn't tell us whether arg is moved or borrowed. The proposed solution
is that auto-borrowing in that context would be deprecated and thus
would require an explicit borrowing: foo(*arg). Now,
On 11/20/13 5:51 AM, Bill Myers wrote:
Have you considered making deref the default instead and requiring moves
to use an explicit move keyword?
Tried it a year ago. It was incredibly noisy. I don't want to go back to
that world.
We saw things like:
let move x = move foo(move y);
On 11/20/13 6:25 AM, spir wrote:
I like this proposal, because afaik it matches the common use case.
Also, it would make things easier to learn, understand, and use, for
people not used to move semantics (even less to it as default / implicit
case). I do struggle with move; making it explicit
On 11/20/13 5:05 AM, Sanghyeon Seo wrote:
I am against this proposal. As I understand, we will still keep
autoref, autoborrow, etc. in method calls. So I don't think inconsistency
argument holds. Neither does local readability argument.
It is a good point that a true emphasis on consistency
On Wed, Nov 20, 2013 at 11:37 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/20/13 5:05 AM, Sanghyeon Seo wrote:
I am against this proposal. As I understand, we will still keep
autoref, autoborrow, etc. in method calls. So I don't think inconsistency
argument holds. Neither does local
One caveat: this e-mail made it sound as if the proposal were
universally favored at the meeting, but I at least feel conflicted,
though I may not have that clear. I started writing a response but
it got long, so I moved it to a blog post:
may mutate `a`, while:
let mut a = ~[y];
push(a, b);
will *not* mutate `a`. Do others have the same expectation?
But isn't there a missing context there ? That 'a' does not necessarily
have to be mutable globally ? But could be constrained... only in the
defined
I'm wondering something. Have the Rust developers considered the
possibility of using references instead of pointers? It seems to me
that this would eliminate a lot of the need for autoderef. Now I'm
not well-equipped to talk about Rust (some of the rules I am totally
ignorant about, e.g. I know
If the concern is mutability rather than details of the indirection used,
then one option would be:
let mut a = ~[y];
push(mut a, b);
It would be a bit odd to do:
let mut x = 0;
incr(mut x);
instead of:
incr(mut x);
as long as you're keeping a strict pointer vs. value mental model, but part
On 11/20/13 10:23 AM, David Piepgrass wrote:
I'm wondering something. Have the Rust developers considered the possibility of using references
instead of pointers? It seems to me that this would eliminate a lot of the need for
autoderef. Now I'm not well-equipped to talk about Rust (some of
On 11/20/2013 09:14 AM, Niko Matsakis wrote:
On Tue, Nov 19, 2013 at 07:19:15AM -0800, Patrick Walton wrote:
The liveness analysis uses the infinite nature of `loop`, and it was
felt that special-casing the `true` boolean like Java does is a hack.
I personally like `loop`. It reads nicely. It
On 11/20/2013 10:37 AM, Brian Anderson wrote:
On 11/20/2013 09:14 AM, Niko Matsakis wrote:
On Tue, Nov 19, 2013 at 07:19:15AM -0800, Patrick Walton wrote:
The liveness analysis uses the infinite nature of `loop`, and it was
felt that special-casing the `true` boolean like Java does is a hack.
On Nov 20, 2013, at 8:52 AM, Corey Richardson co...@octayn.net wrote:
I do, and I agree a lot with Niko's arguments from the meeting. I
agree that * is a bit ugly, but I prefer the ugly syntax to the
ambiguity. I don't find Kevin's argument particularly convincing;
those changes can make your
On Wed, Nov 20, 2013 at 10:27 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/20/13 10:23 AM, David Piepgrass wrote:
snip
It seems to me that the majority of languages have recognized that
references are easier to work with than pointers, and not just because you
can write foo.f()
On Wed, Nov 20, 2013 at 11:23:57AM -0700, David Piepgrass wrote:
I'm wondering something. Have the Rust developers considered the
possibility of using references instead of pointers? It seems to me
that this would eliminate a lot of the need for autoderef. Now I'm
not well-equipped to talk
On Wed, Nov 20, 2013 at 10:37 AM, Brian Anderson bander...@mozilla.comwrote:
Of course, `case` doesn't mean anything in this language...
Hmm, Scala? ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Wed, Nov 20, 2013 at 7:37 PM, Brian Anderson bander...@mozilla.comwrote:
On 11/20/2013 09:14 AM, Niko Matsakis wrote:
On Tue, Nov 19, 2013 at 07:19:15AM -0800, Patrick Walton wrote:
The liveness analysis uses the infinite nature of `loop`, and it was
felt that special-casing the `true`
This is an even sillier idea, but then what about keeping `loop` and
dropping `while`?
I'm not sure this is possible to disambiguate in the grammar. You'd have to
be able to tell the difference between the infinite form:
loop block
...and the conditional form:
loop expr block
Hmm? I think you think I meant that `loop` should accept a condition in
front of the loop, like `while`? In fact my idea was sillier: just replace
all instances of `while foo { bar }` with
loop {
if !foo { break }
bar
}
On Wed, Nov 20, 2013 at 9:56 PM, Benjamin Striegel
Let stick to the semantic:
- while (this condition is true) = execute until this condition becomes
false
- loop = make a loop until a manual break = while true.
However, i think the compiler should check that there is an exit condition
in 'loop' block. I hate reading code with while true without
On 2013-11-20, at 18:27, Patrick Walton pcwal...@mozilla.com wrote:
On 11/19/13 9:42 PM, Tommi wrote:
Our problem is that, given let arg: ~A;, seeing only foo(arg) in code
doesn't tell us whether arg is moved or borrowed. The proposed solution
is that auto-borrowing in that context would be
While I'm trying to argue why the proposed solution is not a full solution to
the proposed problem, I don't even think that the proposed problem is a
problem. Here's why: if you make a call foo(arg) and never use arg after that,
then you don't care if arg gets moved or borrowed. And if you try
This strikes me as a good point. I think the incongruity this would create
between functions and methods -- along with the additional syntactic burden
-- could lead to the use of functions feeling second class in some sense.
Also, how would static methods be treated?
Cheers,
Tim
On Wed, Nov 20,
What about @/Gc types then? You could still potentially reuse them.
--
Ziad
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
While I'm trying to argue why the proposed solution is not a full solution
to the proposed problem, I don't even think that the proposed problem is
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
Here's why: if you make a call foo(arg) and never use arg after that,
then you don't care if arg gets moved or borrowed. And if you try to use
arg afterwards and foo did in fact move it previously, then your IDE is
going to
On Nov 20, 2013, at 6:21 PM, Ziad Hatahet hata...@gmail.com wrote:
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
Here's why: if you make a call foo(arg) and never use arg after that, then
you don't care if arg gets moved or borrowed. And if you try to use arg
On 2013-11-21, at 4:16, Ziad Hatahet hata...@gmail.com wrote:
What about @/Gc types then? You could still potentially reuse them.
--
Ziad
On Wed, Nov 20, 2013 at 5:58 PM, Tommi rusty.ga...@icloud.com wrote:
While I'm trying to argue why the proposed solution is not a full solution to
On Wed, Nov 20, 2013 at 6:00 PM, Gaetan gae...@xeberon.net wrote:
However, i think the compiler should check that there is an exit condition
in 'loop' block. I hate reading code with while true without exit cond,
this is the kind of evilness that shouldnt exist in rust!
A loop without a
41 matches
Mail list logo
