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 which is the expression and
which is the
On Mon, Dec 2, 2013 at 12:43 AM, Eric Reed ecr...@cs.washington.edu wrote:
In either case, I think keeping ~ as sugar for allocating on the exchange
heap would be nice (i.e. ~expr is sugar for ~expr in Unique or put
expr in Unique).
`box expr in place` reads nicely too. I don't know about
On 1 December 2013 03:54, Daniel Micay danielmi...@gmail.com wrote:
I don't understand the point of `do` beyond making zero-parameter
closures look a bit better. If it doesn't even do that, why bother? If
an editor isn't indenting it properly, that's an editor issue. As far
as I can tell, the
if do makes the code more readable or more beautiful, I higly recommend
keeping this sugar syntax. If there are corner cases where do doesn't do
the job, the developer should not use it in these cases.
It's still the same debat, when GIMP had this ugly multi panels system,
developers was saying
I don't think it introduces any ambiguity. The optional in is similar to
the optional else in if.
I'm pretty sure this grammar would suffice:
alloc_expr : ~ expr in_tail ? ;
in_tail : in expr ;
The expr of in_tail would need to be considered a 'place' (some sort of
trait I assume) by the
great work
2013/12/1 Corey Richardson co...@octayn.net
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
Hello,
I lately had a look at Rust and really liked it in many ways. Rust has really everything Im missing in Go ;-). There is something about traits I would like to ask I cant see from the manual. Question is whether you define instance variables in traits or abstract variables like Ceylon and
Hi Oliver,
Glad you're liking Rust so far :)
Currently traits can only have methods (functions that have a self
parameter) and associated functions (functions without a self parameter).
There's a proposal to add inheritance on structs to Rust, which would allow
a trait to extend a struct and
I think `box expr in place` is unnecessarily verbose. I also don't think
`box(place) expr` will be confusing in practice, because it will presumably
look something like `box(Gc) expr`, which should be pretty obvious that Gc is
how it's being boxed, not what's being boxed.
-Kevin
On Dec 2,
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`
-Kevin Ballard
___
Rust-dev mailing
This is my new favorite idea, especially expr@place. It's concise. It reads
expr at place, which is exactly what it does. It goes along with Rust's
putting the type after the value. expr in place could be good too.
On Mon, Dec 2, 2013 at 2:57 AM, Kevin Ballard ke...@sb.org wrote:
With @ going
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
rust-dev-
In general, we need to ensure that for an expression `source as
target` that any borrowed pointers in the type of source are not
obscured [1] by the cast.
A collection of conditions sufficient to enforce this are listed in a
comment in librustc/middle/kind.rs that I think is
Hey, why not set up a Discourse forum? That would be so. much. better. than
a mailing list. As an OSS dev I've been itching to get one myself, but
don't have time or much money to set it up. For Mozilla, though? No problem
I'm sure.
http://www.discourse.org/
Google: discourse hosting.
On 02/12/2013 16:21, David Piepgrass wrote:
That would be so. much. better. than a mailing list.
Hi. Could you expand on this? I don’t necessarily disagree, but as the
one proposing change it’s up to you to convince everyone else :)
--
Simon Sapin
On 12/2/13 8:21 AM, David Piepgrass wrote:
Hey, why not set up a Discourse forum? That would be so. much. better.
than a mailing list. As an OSS dev I've been itching to get one myself,
but don't have time or much money to set it up. For Mozilla, though? No
problem I'm sure.
What do you mean? This suggestion uses @ as an operator, not as a sigil.
-Kevin
On Dec 2, 2013, at 10:23 AM, Patrick Walton pwal...@mozilla.com wrote:
Anything with @ feels like it goes too close to pointer sigils for my taste.
Patrick
spir denis.s...@gmail.com wrote:
On 12/02/2013
But it's nothing like a pointer sigil. @ doesn't appear in the types at
all. It's just the placement allocation operator.
On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton pwal...@mozilla.com wrote:
Anything with @ feels like it goes too close to pointer sigils for my
taste.
Patrick
spir
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
I think the idea was to have the syntax desugar into method calls just like
other existing operators.
There'd be a trait like:
trait BoxT {
fn box(val: T) - Self
}
and something like box expr in place would desugar into
place::box(expr).
One question this poses is why are we requiring the
Is there any way we can use a method and move semantics for this? This
feels pretty natural to me:
let foo = gc_allocator.box(bar);
On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton pwal...@mozilla.com wrote:
Anything with @ feels like it goes too close to pointer sigils for my
taste.
Still too punctuation heavy.
Kevin Ballard ke...@sb.org wrote:
What do you mean? This suggestion uses @ as an operator, not as a
sigil.
-Kevin
On Dec 2, 2013, at 10:23 AM, Patrick Walton pwal...@mozilla.com
wrote:
Anything with @ feels like it goes too close to pointer sigils for my
taste.
That would require an unnecessary move. It needs to be built into the language.
Eric Reed ecr...@cs.washington.edu wrote:
I think the idea was to have the syntax desugar into method calls just
like
other existing operators.
There'd be a trait like:
trait BoxT {
fn box(val: T) - Self
}
and
On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton pwal...@mozilla.com wrote:
That would require an unnecessary move. It needs to be built into the
language.
Devil's advocate - aren't such unnecessary moves really easy for LLVM
to optimize?
___
Rust-dev
Besides, unless you remove the unique default (which I think would be too
verbose) the default allocator reduces to a pointer sigil.
Patrick Walton pwal...@mozilla.com wrote:
Still too punctuation heavy.
Kevin Ballard ke...@sb.org wrote:
What do you mean? This suggestion uses @ as an operator,
Only if you SROA and inline the constructor, I think.
comex com...@gmail.com wrote:
On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton pwal...@mozilla.com
wrote:
That would require an unnecessary move. It needs to be built into the
language.
Devil's advocate - aren't such unnecessary moves really
I'm not sure that discussion forums are the best alternative to the typical
foo-users mailing list. Topics are generally less about discussion and
more about getting a quick answer to a problem; IRC is okay for this at the
moment, but once Rust stabilizes I'd much prefer just using StackOverflow
~ would still be the unique default. @ would require a place (because there's
no placement without a place). Just because C++ uses the same operator for
regular allocation and for placement doesn't mean we have to do the same. As
it's been pointed out already, C++'s use of `new` for placement
And @ even makes sense for what it's doing (placing something at somewhere)
when compared with most operators.
On Mon, Dec 2, 2013 at 12:04 PM, Kevin Ballard ke...@sb.org wrote:
~ would still be the unique default. @ would require a place (because
there's no placement without a place). Just
When I started my old Rust PPA (now superseded), the first user to
email me was an engineer from China who was getting ready to give a
talk introducing Rust to a programming user group in Guǎngzhōu bigger
than any of the Rust-specific meetups we've ever had yet in the San
Francisco Bay area.
The compiler still handles it, and there are still tests for it. I
think it's more of a not 1.0 priority, than anything else.
On Mon, Dec 2, 2013 at 11:31 PM, Kevin Cantu m...@kevincantu.org wrote:
When I started my old Rust PPA (now superseded), the first user to
email me was an engineer from
On 02/12/2013 16:21, David Piepgrass wrote:
That would be so. much. better. than a mailing list.
Hi. Could you expand on this? I don?t necessarily disagree, but as the
one proposing change it?s up to you to convince everyone else :)
--
Simon Sapin
Okay, well, I've never liked mailing
Well there's always r/rust/ http://www.reddit.com/r/rust/. It usually
works pretty well.
On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass qwertie...@gmail.comwrote:
On 02/12/2013 16:21, David Piepgrass wrote:
That would be so. much. better. than a mailing list.
Hi. Could you expand on
35 matches
Mail list logo
