I don't want stack once functions, because I feel that their use cases are
better served with RAII, which serves the same purposes without rightward drift
and without forcing LLVM to perform devirtualization.
Patrick
Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for
The main reason for do's existence is to make task spawning look nice. The
closure inference was removed throughout the language because it masked
allocation and doesn't work well with custom smart pointers. If do is still
causing confusion, I'd rather just remove it entirely.
Patrick
Chris
Plain new would allocate in the exchange heap by default.
And yes, C++ syntax has always been a goal. That's why Rust has had curly
braces from day one, for example. Of course it deviates when C++ syntax would
lead to lack of expressivity (using let and colons before types allows for
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 30 Nov 2013, at 6:55 pm, spir denis.s...@gmail.com wrote:
Since this issue is all about placing something into memory, why not use
'mem' ?
Denis
Some folks have suggested using `alloc`.
___
Rust-dev mailing list
Rust-dev@mozilla.org
`new` isn't self-documenting. It's merely consistent with C++, but consistency
with C++ cannot be considered self-documentation because there are a great many
programmers out there who have never touched C++ (or any language with a `new`
operator). To someone who hasn't encountered `new`
On 11/30/13 10:01 AM, Kevin Ballard wrote:
`new` isn't self-documenting. It's merely consistent with C++, but
consistency with C++ cannot be considered self-documentation because
there are a great many programmers out there who have never touched C++
(or any language with a `new` operator). To
Would it not be possible to have new be a keyword, yet not a reserved
word (since they are not the same thing). This leaves the possibility of
using it as a method name (e.g. Struct::new()), while still using it as an
operator.
--
Ziad
On Sat, Nov 30, 2013 at 1:07 AM, David Rajchenbach-Teller
On Nov 30, 2013, at 1:07 AM, David Rajchenbach-Teller dtel...@mozilla.com
wrote:
On 11/30/13 10:01 AM, Kevin Ballard wrote:
`new` isn't self-documenting. It's merely consistent with C++, but
consistency with C++ cannot be considered self-documentation because
there are a great many
Thanks for this explanation about ~! Can you add a paragraph in the
tutorial or manual?
Le 30 nov. 2013 08:10, Kevin Ballard ke...@sb.org a écrit :
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
If looking like c++ is a goal, why not using the same naming convention as
it for constructor? Having an init () function or new () function is
generally a bad idea, it is just a name.
I prefere personnally the new name.
What i dont really like is the fn keyword, it is too short. func or
function
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 the library,
sigils seem to make less sense to
On 11/30/2013 10:01 AM, Brendan Zabarauskas wrote:
Some folks have suggested using `alloc`.
We could call it `malloc` and make it a library function!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Once stack functions have nothing to do with RAII. It is about container
manipulation methods. Consider the mangle function of a hashmap for
example. It makes perfect sense to be able to access a borrowed pointer and
also consume an owned pointer inside the mangle actions. This is currently
On Sat, 2013-11-30 at 09:34 +0200, Oren Ben-Kiki wrote:
This is a lose-lose situation. If the container takes a `proc`, then
Rust complains that it can't capture the non-send-able variable. But
if the container takes a stack closure, then Rust complains it can't
use the owned variable. Of
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an action
parameter to take the extra tuple in every container or container-like
type. And
If do is still causing confusion, I'd rather just remove it entirely.
I rather like `do`. I agree that if it's confusing it should be considered
for removal, but IMO the confusion here stems from familiarity with the
prior, obsolete semantics rather than any inherent problem with the
construct
On Sat, Nov 30, 2013 at 9:34 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an action
On Sat, Nov 30, 2013 at 5:24 AM, György Andrasek jur...@gmail.com wrote:
What really bugs me about `~` is that it conflates the idea of lifetime and
ownership (which is a zero-cost annotation) with allocation (which is an
actual expensive operation to stay away from). This wasn't a problem
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 Sat, Nov 30, 2013 at 12:18 PM, spir denis.s...@gmail.com wrote:
Looks quite nice :-) and nicely separates syntax items for kind of
pointing and watch, runtime mem alloc ahead!. (However, as others have
noted, 'new' in itself means nothing; for non-C++-ers like myself, a proper
term would
On 11/30/13 3:25 AM, Oren Ben-Kiki wrote:
Once stack functions have nothing to do with RAII. It is about container
manipulation methods. Consider the mangle function of a hashmap for
example. It makes perfect sense to be able to access a borrowed pointer
and also consume an owned pointer inside
While we're changing this stuff, I'd like to see lambdas allow return, now
that the need for forbidding that is gone, IIRC. That's more likely to
continually trip me up than unusual allocation mechanisms.
Kevin
On Nov 30, 2013 10:02 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC. That's more likely
to continually trip me up than unusual allocation mechanisms.
No objections here.
Patrick
Hello folks,
I'm a French student finishing his study this year and a teacher gave us
a project to finish by the end of the year which is to modify (or add) a
small feature to an existing interpreter (or compiler, language,...)
such as a primitive or a control structure.
I'm pretty new to
On 11/30/2013 07:41 PM, Pierre Talbot wrote:
Do you have suggestions that could fit well for this kind of project?
Make the following code compile:
```
fn foo() {
bar()
fn bar() {}
}
```
i.e. allow nested function declarations after a semicolonless return
expression.
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
Le 30 nov. 2013 19:59, György Andrasek jur...@gmail.com a écrit :
On 11/30/2013 07:41 PM, Pierre Talbot wrote:
Do you have suggestions that could fit
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
This isn't the point of this thread, and also I don't think anybody is
willing to revisit this issue. Consider that ship as having sailed beyond
the
Should an issue for this be filed then?
--
Ziad
On Sat, Nov 30, 2013 at 10:20 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC.
Currently our `for` loops are implemented strangely. In essence, right now
a `for` loop is just syntax sugar that gets expanded during the parsing
stage. This was easy to implement, but it means that our error messages
around `for` loops are strange and it limits our ability to do more
intelligent
On Nov 30, 2013, at 10:02 AM, Patrick Walton pcwal...@mozilla.com wrote:
I don't agree in general that the right solution for every problem that can
be solved through the type system is in the type system. Every type system
feature has a cost; when something can be done via what's already
On Nov 30, 2013, at 10:20 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 10:05 AM, Kevin Cantu wrote:
While we're changing this stuff, I'd like to see lambdas allow return,
now that the need for forbidding that is gone, IIRC. That's more likely
to continually trip me up than
Just to mention in passing - there's a related principle that converting a
block to a closure shouldn't change its semantics. This obviously doesn't
fully work because of return/break/continue; that said, if a block without
such flow control constructs is wrapped into a closure, you'd expect it to
(I forget the name, sadly)
This is usually referred to as Tennet's Correspondence Principle:
http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html
...though it is sometimes debated whether or not the modern interpretation
of this principle is actually what Tennet
On 11/30/13 1:01 AM, Kevin Ballard wrote:
Is consistency with C++ really so important as to break what is now a
pretty strong library convention?
We've broken conventions so much in the past. I don't think backwards
compatibility is a concern yet.
Especially since the replacement
On 11/30/13 6:34 AM, Oren Ben-Kiki wrote:
That would help a bit, but it would still require the programmer to
manually setup and teardown the tuples, pass them to the closure, and so
on. We'll also need to change each and every function that takes an
action parameter to take the extra tuple in
On 11/30/13 1:17 PM, Patrick Walton wrote:
Especially since the replacement
convention, as seen in PR #10697, is pretty bad (namely, using ::init()
instead of ::new(); init() to me seems as though it should merely
initialize a value, not construct a new value. Heck, the old Path
convention of
Sorry for this offtopic subject..
Le 30 nov. 2013 20:20, Benjamin Striegel ben.strie...@gmail.com a écrit
:
Is is possible to get rid of this returnless return?
I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
This isn't the point of this thread,
On 11/30/13 1:32 PM, Gaetan wrote:
Cannot this allocations be implicit to avoid sigils everywhere?
Coercions between `T` and `SmahtT` would make it really hard to see
where you're allocating.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 11/30/13 12:04 PM, Oren Ben-Kiki wrote:
Just to mention in passing - there's a related principle that converting
a block to a closure shouldn't change its semantics. This obviously
doesn't fully work because of return/break/continue; that said, if a
block without such flow control constructs
There were several threads about this,
https://mail.mozilla.org/pipermail/rust-dev/2013-October/006105.html for
example. I don't see how that code can be converted to RAII at all. Sure it
can be done with cells, or possibly with tuples (though, well, doing this
_manually_? shudder). It really just
On 11/30/13 1:24 AM, Kevin Ballard wrote:
Speaking of `new (x + y)`, has any thought been given to
differentiating `new (expr)` from placement-new?
Yeah, this came up. We can just define new followed by `(` to resolve in
favor of placement new.
Given all this, my inclination at this point
On 11/30/13 1:54 PM, Oren Ben-Kiki wrote:
There were several threads about this,
https://mail.mozilla.org/pipermail/rust-dev/2013-October/006105.html for
example. I don't see how that code can be converted to RAII at all. Sure
it can be done with cells, or possibly with tuples (though, well,
Like I said, this is a boiled-down example of the essence of the problem.
Yes, the hashmap mangle is an example, and the option map, and similar
standard container methods, and quite a few similar functions in my own
specific container classes (contrary to popular opinion, in non-trivial
projects
On Sat, Nov 30, 2013 at 1:54 PM, Patrick Walton pcwal...@mozilla.comwrote:
The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that. It's not that I'm unconcerned about `new()(1 +
It's also not clear to me how once fn can decompose into a trait in the
future. The goal in the future is to make fn() a type of trait, to allow for
C++-like zero-indirection closures. The different types of functions that we
have today correspond to different self parameters: |A|-B corresponds
Hi all,
I'm trying to learn rust and ran into an error message I don't
understand, and would appreciate some help. This code:
trait T {}
fn f'a, V: T(v: 'a V) - 'a T {
v as 'a T
}
is rejected with this error message:
trait-cast.rs:4:4: 4:5 error: value may contain borrowed pointers; add
On Sat, Nov 30, 2013 at 10:17 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 11/30/13 1:01 AM, Kevin Ballard wrote:
As
for placement new, while it needs to be supported in some fashion, it's
going to be used pretty rarely, such that I don't think it's worth
reserving a keyword just for
It's okay, it's our own fault for not having yet written a document
entitled Things That Absolutely Will Not Change And That We Are Tired Of
Discussing. :P
On Sat, Nov 30, 2013 at 4:34 PM, Gaetan gae...@xeberon.net wrote:
Sorry for this offtopic subject..
Le 30 nov. 2013 20:20, Benjamin
Presumably Arc, MutexArc, and friends are going to be used with placement new
to save one move operation. So basically any Rust program that uses shared
memory (except for maybe pure fork-join code) will use placement new. I imagine
that's pretty common.
Your conflicted feelings pretty much
The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that.
I much prefer `new` to `alloc`. It *is* a shame that `foo::new()` has to
change, but `alloc` is much grosser than `init`. And
I must be hitting some weird edge case inside Rust or LLVM where I'm right
on the line between inlining or not a block of code. I've been playing
around with the collatz fns from:
http://www.mit.edu/~mtikekar/posts/stream-fusion.html
but I stumbled upon two weird mis-optimizations at
In Rust new(place) expr means call a special method on 'place' to create
room for 'expr', then evaluate 'expr' with its destination set to that newly
created location. A full description of destination is beyond the scope of
this email :) But for function calls in particular, it means the
On Sat, Nov 30, 2013 at 11:35 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that.
I much prefer `new` to `alloc`. It *is*
Right, I agree with this. Kevin's argument that C++ new has different
behavior is valid though, and makes me conflicted.
BTW, I was thinking about make as well. Go is precedent that both new and
make can coexist (though not without controversy...) Old Rust used to use
mk as the constructor
On Fri, Nov 29, 2013 at 11:34 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code.
On Sat, Nov 30, 2013 at 12:26 AM, Patrick Walton pwal...@mozilla.com
wrote:
The main reason for do's existence is to make task spawning look nice.
I've got to say
On 30.11.2013 23:50, Patrick Walton wrote:
Right, I agree with this. Kevin's argument that C++ new has different
behavior is valid though, and makes me conflicted.
BTW, I was thinking about make as well. Go is precedent that both
new and make can coexist (though not without controversy...)
On Sat, Nov 30, 2013 at 8:51 PM, Florian Zeitz flo...@babelmonkeys.de wrote:
Personally I would suggest calling this operator `box`, since it boxes
its argument into a newly allocated memory box.
I really like this proposal. I've watched this thread and the original
`new` proposal with
I'm still very much a fan of leaving ~ as the allocation operator. Despite what
Patrick says, I'm pretty sure the reason why users are confused about it is
purely due to sub-par documentation, and not due to any actual inherent
problems with using a non-alphabetic symbol as an operator. Heck,
On Sat, Nov 30, 2013 at 9:30 PM, Kevin Ballard ke...@sb.org wrote:
I'm still very much a fan of leaving ~ as the allocation operator. Despite
what Patrick says, I'm pretty sure the reason why users are confused about it
is purely due to sub-par documentation, and not due to any actual
Welcome to another issue of *This Week in Rust*, a weekly newsletter
summarizing Rust's progress and community activity. As always, if you have
something you'd like to be featured, just [send me an
email](mailto:co...@octayn.net?subject=This Week in Rust Suggestion).
Last week was very slow, but
On Sat, Nov 30, 2013 at 7:55 PM, Tony Arcieri basc...@gmail.com wrote:
On Fri, Nov 29, 2013 at 11:34 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code.
On Sat, Nov 30, 2013 at 12:26 AM, Patrick Walton pwal...@mozilla.com
wrote:
The main reason
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to the language with Rust for Rubyists.
It might seem like a small thing but
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes a
lot of code look downright ugly. I'd rather it used a more Ruby-ish notation
though, I find that putting the `do` far away from the `{ ... }`
On 11/30/13 7:35 PM, Brendan Zabarauskas wrote:
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of
it
makes a lot of code look downright ugly. I'd rather it used a more
Ruby-ish notation though, I find that
On Sat, Nov 30, 2013 at 10:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to
On 11/30/13 7:43 PM, Corey Richardson wrote:
Maybe `do` can just change from procs to closures. I can't really say
how often I've actually wanted a proc. Task bodies are a far minority
compared to other uses of do, from the backlash, and I don't find
`spawn(proc() { ... })` that unappealing.
I
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will probably appeal to the people
that Steve Klabnik is drawing to the
On 11/30/13 7:50 PM, Kevin Ballard wrote:
do spawn proc() {
..
}
That's essentially just as verbose as not having do.
And yes, I know do originally existed to make spawning nicer, but
that's not really that ugly, and allows for using `do` with stack
closures (which, in code I've seen,
On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard ke...@sb.org wrote:
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do syntax is one of the things that
appeals to me about Rust, and will
On 1 Dec 2013, at 1:45 pm, Patrick Walton pcwal...@mozilla.com wrote:
the experiment of using blocks in place of RAII for stuff like with_c_str
or unkillable has failed: it leads to too much rightward drift.
Patrick
I guess I can agree with that. I remember when I first started with Rust
On Nov 30, 2013, at 7:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard ke...@sb.org wrote:
On Nov 30, 2013, at 7:28 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/30/13 7:25 PM, Michael Letterle wrote:
I've got to say that the do
On 11/30/13 8:06 PM, Brendan Zabarauskas wrote:
On 1 Dec 2013, at 1:45 pm, Patrick Walton pcwal...@mozilla.com wrote:
the experiment of using blocks in place of RAII for stuff like with_c_str or
unkillable has failed: it leads to too much rightward drift.
Patrick
I guess I can agree with
Eh, I'm as fine with `box` as I am with `new`. Does seem a bit like jargon,
though. Though maybe it will herald a return to the days when we really
played up the shipping container flavor. Crates and cargo, anyone? :)
On Sun, Dec 1, 2013 at 12:42 AM, Patrick Walton pcwal...@mozilla.comwrote:
74 matches
Mail list logo
