Re: [rust-dev] Placement new and the loss of `new` to keywords
This is an interesting thread. A few points: - box makes a lot more sense than new; as others have pointed out, the latter maps to a different concept in C++ which makes it familiar in the worst way. - Foo::init is terrible, agreed, but Foo::new is less than ideal as well. Foo::create might be better. Just read this aloud: this function news a value. What? That makes no sense. This function creates a value. Much better, isn't it? Point being, it should be a verb. JavaScript does it with Object.create, so there's precedent. - placement new might be common in Servo and browser engines, but it's not that common in most C++. After 10 years and 200k+ LOC of C++ across many, many different programs and paradigms I've yet to use it once. Sure, that's just one person's experience but others seem to be echoing the same sentiment. I'm not saying let's not have placement new, just that we shouldn't put on an undeserved pedestal. On Dec 2, 2013 11:39 AM, Patrick Walton pwal...@mozilla.com wrote: 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 easy for LLVM to optimize? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On 12/3/13 12:34 AM, Val Markovic wrote: This is an interesting thread. A few points: - box makes a lot more sense than new; as others have pointed out, the latter maps to a different concept in C++ which makes it familiar in the worst way. - Foo::init is terrible, agreed, but Foo::new is less than ideal as well. Foo::create might be better. Just read this aloud: this function news a value. What? That makes no sense. This function creates a value. Much better, isn't it? Point being, it should be a verb. JavaScript does it with Object.create, so there's precedent. - placement new might be common in Servo and browser engines, but it's not that common in most C++. After 10 years and 200k+ LOC of C++ across many, many different programs and paradigms I've yet to use it once. Sure, that's just one person's experience but others seem to be echoing the same sentiment. I'm not saying let's not have placement new, just that we shouldn't put on an undeserved pedestal. Rust and C++ are different. You don't use placement `new` for `shared_ptr` in C++; however, you will use placement `new` (or `box`) for `RC` in Rust (the equivalent). For this reason I suspect that placement `new` will be much commoner in Rust than in C++. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
+1 for `expr @ place` On 02.12.2013 11:57, 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` -Kevin Ballard ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
If `expr @ place` suffices then you'd think that re-using `in` keyword as per `expr in place` would also work, but I believe we rejected that for technical reasons in past discussions. And if those technical reasons no longer apply, I'd like to motion that `in` looks way better than `@` there. :) On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister michaelwoeris...@posteo.de wrote: +1 for `expr @ place` On 02.12.2013 11:57, 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` -Kevin Ballard ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On Tue, Dec 3, 2013 at 3:41 AM, Patrick Walton pcwal...@mozilla.com wrote: On 12/3/13 12:34 AM, Val Markovic wrote: This is an interesting thread. A few points: - box makes a lot more sense than new; as others have pointed out, the latter maps to a different concept in C++ which makes it familiar in the worst way. - Foo::init is terrible, agreed, but Foo::new is less than ideal as well. Foo::create might be better. Just read this aloud: this function news a value. What? That makes no sense. This function creates a value. Much better, isn't it? Point being, it should be a verb. JavaScript does it with Object.create, so there's precedent. - placement new might be common in Servo and browser engines, but it's not that common in most C++. After 10 years and 200k+ LOC of C++ across many, many different programs and paradigms I've yet to use it once. Sure, that's just one person's experience but others seem to be echoing the same sentiment. I'm not saying let's not have placement new, just that we shouldn't put on an undeserved pedestal. Rust and C++ are different. You don't use placement `new` for `shared_ptr` in C++; however, you will use placement `new` (or `box`) for `RC` in Rust (the equivalent). For this reason I suspect that placement `new` will be much commoner in Rust than in C++. Patrick To expand on this, C++ has functions like `make_shared` (C++11), `make_unique` (C++14) and even container methods to build an object in-place without a move (`emplace`, `emplace_back`, etc.). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
I’m curious what the technical reasons are, because I’m not sure why it wouldn’t work (it’s just an operator, after all). In any case, I prefer @ for aesthetic reasons. Also, this operator should probably bind pretty tightly (e.g. 1 * 2@Gc would place the 2 not the 1*2), but it’s often confusing to have word operators bind tightly. For example, I think `as` binds reasonably tightly, but I still can’t remember its exact precedence. -Kevin On Dec 3, 2013, at 9:16 AM, Benjamin Striegel ben.strie...@gmail.com wrote: If `expr @ place` suffices then you'd think that re-using `in` keyword as per `expr in place` would also work, but I believe we rejected that for technical reasons in past discussions. And if those technical reasons no longer apply, I'd like to motion that `in` looks way better than `@` there. :) On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister michaelwoeris...@posteo.de wrote: +1 for `expr @ place` On 02.12.2013 11:57, 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` -Kevin Ballard ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 place. Personally, I like ~ so I'd like ~expr in place, but if people absolutely insist on scrapping ~ then I'd suggest put expr in place. 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). I guess we could use new or box instead of put, but I like put over either. On Sun, Dec 1, 2013 at 6:31 AM, Tiffany Bennett tiff...@stormbit.netwrote: I agree with the `box` name, it's far less jarring than `new (1+1)`. On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn tku...@cmu.edu wrote: On Sun, Dec 1, 2013 at 8:04 AM, spir denis.s...@gmail.com wrote: On 12/01/2013 02:51 AM, Florian Zeitz wrote: If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. +++ to all 3 points Denis I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 any ambiguity in the syntax though. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 typechecker. Ending in_tail with an expr shouldn't be a problem (lambda_expr does it). The parser can unambiguously tell if there is an in_tail present by simply checking for the in keyword. On Mon, Dec 2, 2013 at 12:56 AM, Ziad Hatahet hata...@gmail.com wrote: On Mon, Dec 2, 2013 at 12:43 AM, Eric Reed ecr...@cs.washington.eduwrote: 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 any ambiguity in the syntax though. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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, 2013, at 12:43 AM, Eric Reed ecr...@cs.washington.edu 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 which is the expression and which is the place. Personally, I like ~ so I'd like ~expr in place, but if people absolutely insist on scrapping ~ then I'd suggest put expr in place. 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). I guess we could use new or box instead of put, but I like put over either. On Sun, Dec 1, 2013 at 6:31 AM, Tiffany Bennett tiff...@stormbit.net wrote: I agree with the `box` name, it's far less jarring than `new (1+1)`. On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn tku...@cmu.edu wrote: On Sun, Dec 1, 2013 at 8:04 AM, spir denis.s...@gmail.com wrote: On 12/01/2013 02:51 AM, Florian Zeitz wrote: If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. +++ to all 3 points Denis I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 which is the expression and which is the place. Personally, I like ~ so I'd like ~expr in place, but if people absolutely insist on scrapping ~ then I'd suggest put expr in place. 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). I guess we could use new or box instead of put, but I like put over either. What about: box(place, expr) box(expr, place)# better for me box expr in/to place# pure syntactic magic ? The latter may seem weird, but anyway box or new or whatever aren't functions in the ordinary sense. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 denis.s...@gmail.com wrote: 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis -- Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 place to be specified
all the time?
Why not let type inference handle deciding the place most of the time?
On Mon, Dec 2, 2013 at 10:46 AM, Erick Tryzelaar
erick.tryzel...@gmail.comwrote:
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.comwrote:
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 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 this give:
let foo = ~ bar;
let placed_foo = bar @ place;
?
Yet another solution, just for fun, using the fact that pointers are
supposed to
point to:
let foo = - bar;
let placed_foo = bar - place;
Denis
--
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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. Patrick spir denis.s...@gmail.com wrote: 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis -- Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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. Patrick spir denis.s...@gmail.com wrote: 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 something like box expr in place would desugar into
place::box(expr).
One question this poses is why are we requiring the place to be
specified
all the time?
Why not let type inference handle deciding the place most of the
time?
On Mon, Dec 2, 2013 at 10:46 AM, Erick Tryzelaar
erick.tryzel...@gmail.comwrote:
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.comwrote:
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 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 this give:
let foo = ~ bar;
let placed_foo = bar @ place;
?
Yet another solution, just for fun, using the fact that pointers
are supposed to
point to:
let foo = - bar;
let placed_foo = bar - place;
Denis
--
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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, 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 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 easy for LLVM to optimize? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
~ 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 is kind of quite strange, since it doesn't actually allocate anything. As for too punctuation heavy, why the hate on punctuation? Operators have a long history of use in programming languages to great effect. I don't get why operators are now suddenly bad. User-overloadable operators are contentious, certainly, but this isn't an overloadable operator. -Kevin On Dec 2, 2013, at 11:38 AM, Patrick Walton pwal...@mozilla.com wrote: 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, 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 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 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 is kind of quite strange, since it doesn't actually allocate anything. As for too punctuation heavy, why the hate on punctuation? Operators have a long history of use in programming languages to great effect. I don't get why operators are now suddenly bad. User-overloadable operators are contentious, certainly, but this isn't an overloadable operator. -Kevin On Dec 2, 2013, at 11:38 AM, Patrick Walton pwal...@mozilla.com wrote: 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, 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 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 this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to point to: let foo = - bar; let placed_foo = bar - place; Denis -- Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On Sun, Dec 1, 2013 at 8:04 AM, spir denis.s...@gmail.com wrote: On 12/01/2013 02:51 AM, Florian Zeitz wrote: If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. +++ to all 3 points Denis I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 destructuring assignment, for example), but in general if the C++ way fits the language we go with it. 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 me, as punctuation is a non-extensible closed set to borrow a term from linguistics. Besides, they were a very frequent source of confusion. Documentation is good, but being self-documenting is better. Patrick Kevin Ballard ke...@sb.org wrote: On Nov 29, 2013, at 11:26 PM, Patrick Walton pwal...@mozilla.com wrote: There's also the fact that the exchange heap is the default place to allocate, so anything that needs an object (e.g. in) doesn't work, as in Unique would probably be too verbose. `in Unique` is too verbose, but `new(Unique)` isn't? Looking like C++ is a goal of Rust, in any case... I thought C++ performance was a goal. Since when is C++ syntax considered to be a goal? -Kevin Patrick Kevin Ballard ke...@sb.org 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 exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving `new` as a keyword? Here's a few random ideas (where val is the value expression and place is the place expression): ~in(place) val in(place) ~val ~val in place (assuming this isn't somehow ambiguous) ~~val in place (the existing ~~val would have to be written ~(~val)) ~~(place) val (the existing ~~val would have to be written ~(~val)) ~place val ~=place val ~place val(this looks like an arrow pointing to the place) ~(place) val Personally I think `~in(place) val` is perfectly fine. It's not the prettiest of syntaxes, but placement new should be very rare, and this allows us to avoid reserving `new` and continue to use ~ as the allocation operator. -Kevin Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. Since this issue is all about placing something into memory, why not use 'mem' ? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
`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` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. Is consistency with C++ really so important as to break what is now a pretty strong library convention? 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 using Path(..) is better than Path::init(..)). As I've been arguing, `new` is not inherently self-documenting, and the confusion around ~ can be solved with proper documentation (just as a C++ programmer needs to be taught that `new` is the allocation operator, a Rust programmer would be taught that ~ is the allocation operator). 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 that. We have existing keywords and syntactical tokens that can be used. Among my previous suggestions I'm fond of both `~in(place) val` and `~(place) val`. We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. And semantically speaking, both `new` and ~ are the same operator, so I don't think the closed-set nature of sigils is an issue in this case. -Kevin On Nov 30, 2013, at 12:34 AM, Patrick Walton pwal...@mozilla.com wrote: 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 destructuring assignment, for example), but in general if the C++ way fits the language we go with it. 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 me, as punctuation is a non-extensible closed set to borrow a term from linguistics. Besides, they were a very frequent source of confusion. Documentation is good, but being self-documenting is better. Patrick Kevin Ballard ke...@sb.org wrote: On Nov 29, 2013, at 11:26 PM, Patrick Walton pwal...@mozilla.com wrote: There's also the fact that the exchange heap is the default place to allocate, so anything that needs an object (e.g. in) doesn't work, as in Unique would probably be too verbose. `in Unique` is too verbose, but `new(Unique)` isn't? Looking like C++ is a goal of Rust, in any case... I thought C++ performance was a goal. Since when is C++ syntax considered to be a goal? -Kevin Patrick Kevin Ballard ke...@sb.org 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 exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 someone who hasn't encountered `new` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. I believe that Patrick's argument is that the primary target of Rust is people who are already familiar with C++. To them, `new` will be self-documenting. Programmers who are not familiar with `new` (who are getting rare these days) will still need to learn a new construct, just as they would with sigils. I do not have a very strong opinion, but I believe that `new` is indeed a good way to astonish the least amount of newcomers. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 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 programmers out there who have never touched C++ (or any language with a `new` operator). To someone who hasn't encountered `new` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. I believe that Patrick's argument is that the primary target of Rust is people who are already familiar with C++. To them, `new` will be self-documenting. Programmers who are not familiar with `new` (who are getting rare these days) will still need to learn a new construct, just as they would with sigils. I do not have a very strong opinion, but I believe that `new` is indeed a good way to astonish the least amount of newcomers. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 programmers out there who have never touched C++ (or any language with a `new` operator). To someone who hasn't encountered `new` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. I believe that Patrick's argument is that the primary target of Rust is people who are already familiar with C++. To them, `new` will be self-documenting. Programmers who are not familiar with `new` (who are getting rare these days) will still need to learn a new construct, just as they would with sigils. I do not have a very strong opinion, but I believe that `new` is indeed a good way to astonish the least amount of newcomers. Assuming for the moment that most Rust programmers will, both now and in the future, have started with C++, we still need to document the allocation operator in such a way that people who have not seen it before will understand it. Given that, I do not see that there is much benefit to using `new` over ~ for the sake of familiarity to a subset of programmers, as that does not absolve us from our need for good documentation. Not to mention the proposed `new` operator here will actually behave differently than it does in C++ anyway, which means that familiarity might actually be a bad thing as it will lead users to think they understand the operator when they don't! Notably, in C++ the `new` operator invokes a class constructor, whereas in Rust it allocates an arbitrary expression's value into a memory location (typically on the exchange heap, or into an explicit location with placement new). What is a C++ programmer supposed to think when they see `new (x + y)`? Speaking of `new (x + y)`, has any thought been given to differentiating `new (expr)` from placement-new? AFAIK whitespace after keywords/identifiers is not significant anywhere else in the language, so one would expect `new (foo)` to be an attempt at placement-new with the destination expression `foo`, just like `new(foo)`. But if that's the case, how does one allocate the value of a parenthesized expression? `~(x + y)` is perfectly legal today. The only appropriate solution I can think of is `new() (x + y)`, which is ugly and surprising. Given all this, my inclination at this point is to say that trying to piggyback on C++ programmers' familiarity of `new` is actually a really bad idea, as Rust's allocation operator differs in a few important ways from C++. In fact, offhand I can't think of any language with a `new `operator that uses it for something other than invoking a class constructor. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 documentation. The only reason why a user would know that `new Foo` allocates is because they've been exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving `new` as a keyword? Here's a few random ideas (where val is the value expression and place is the place expression): ~in(place) val in(place) ~val ~val in place (assuming this isn't somehow ambiguous) ~~val in place (the existing ~~val would have to be written ~(~val)) ~~(place) val (the existing ~~val would have to be written ~(~val)) ~place val ~=place val ~place val(this looks like an arrow pointing to the place) ~(place) val Personally I think `~in(place) val` is perfectly fine. It's not the prettiest of syntaxes, but placement new should be very rare, and this allows us to avoid reserving `new` and continue to use ~ as the allocation operator. -Kevin -- Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 would have been perfectly acceptable. Le 30 nov. 2013 10:02, Kevin Ballard ke...@sb.org a écrit : `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` before, an equally-valid interpretation of `new Foo` would be to construct a `Foo` value by invoking a standard initializer, returning it by-value. Is consistency with C++ really so important as to break what is now a pretty strong library convention? 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 using Path(..) is better than Path::init(..)). As I've been arguing, `new` is not inherently self-documenting, and the confusion around ~ can be solved with proper documentation (just as a C++ programmer needs to be taught that `new` is the allocation operator, a Rust programmer would be taught that ~ is the allocation operator). 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 that. We have existing keywords and syntactical tokens that can be used. Among my previous suggestions I'm fond of both `~in(place) val` and `~(place) val`. We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. And semantically speaking, both `new` and ~ are the same operator, so I don't think the closed-set nature of sigils is an issue in this case. -Kevin On Nov 30, 2013, at 12:34 AM, Patrick Walton pwal...@mozilla.com wrote: 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 destructuring assignment, for example), but in general if the C++ way fits the language we go with it. 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 me, as punctuation is a non-extensible closed set to borrow a term from linguistics. Besides, they were a very frequent source of confusion. Documentation is good, but being self-documenting is better. Patrick Kevin Ballard ke...@sb.org wrote: On Nov 29, 2013, at 11:26 PM, Patrick Walton pwal...@mozilla.com wrote: There's also the fact that the exchange heap is the default place to allocate, so anything that needs an object (e.g. in) doesn't work, as in Unique would probably be too verbose. `in Unique` is too verbose, but `new(Unique)` isn't? Looking like C++ is a goal of Rust, in any case... I thought C++ performance was a goal. Since when is C++ syntax considered to be a goal? -Kevin Patrick Kevin Ballard ke...@sb.org 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 exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 me 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 with `@`, but it's gone now. My choice would be to keep `~` in types, but use `new` for allocation: let foo: ~Foo = new Foo(bar); ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 with `@`, but it's gone now. My choice would be to keep `~` in types, but use `new` for allocation: let foo: ~Foo = new Foo(bar); It doesn't conflate these ideas. There's no useful property of `~T` if you don't need the pointer-size invariant provided by dynamic memory allocation. A plain `T` is already owned, wrapping it as `~T` just adds an extra destructor and makes it the size of a pointer - it has value semantics either way. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 the library, sigils seem to make less sense to me 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 with `@`, but it's gone now. My choice would be to keep `~` in types, but use `new` for allocation: let foo: ~Foo = new Foo(bar); 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 be better.) Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 be better.) Denis You would still need an allocation to get any `~T` and in fact it's *deallocation* that's expensive with most allocators. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 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 using Path(..) is better than Path::init(..)). As I've been arguing, `new` is not inherently self-documenting, and the confusion around ~ can be solved with proper documentation (just as a C++ programmer needs to be taught that `new` is the allocation operator, a Rust programmer would be taught that ~ is the allocation operator). That was the justification for sigils, but it hasn't worked so far. I've seen many people trying Rust get stuck on the sigils and move to other languages. 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 that. Placement new is not going to be used rarely. In Servo, for example, it's used all over the place. We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. That flavor is much of the reason for Rust's reputation as an overly complex language. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 using Path(..) is better than Path::init(..)). Honestly, I'm not in love with `init` either. I don't find it particularly intuitive, and alternatives are welcome. But I do think that using a sigil for allocation and the lack of placement new are problems that needs fixing. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 is to say that trying to piggyback on C++ programmers' familiarity of `new` is actually a really bad idea, as Rust's allocation operator differs in a few important ways from C++. In fact, offhand I can't think of any language with a `new `operator that uses it for something other than invoking a class constructor. Well, there aren't many languages with allocation operators period: the vast majority of languages implicitly allocate on the heap. Of those languages with an allocation operator that isn't a function, it's universally `new` as far as I know. 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 + 2)` being weird: it's that I'm more concerned about what's not going to make C++ programmers run away. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 + 2)` being weird: it's that I'm more concerned about what's not going to make C++ programmers run away. Patrick +1 for `alloc`. It is straightforward and to the point. Another important (IMO) advantage is that we would be able to use `new()` as a method name, instead of `init()`, which is very confusing, and conveys the wrong meaning. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 that. Placement new is not going to be used rarely. In Servo, for example, it's used all over the place. Can that (or even the totality of currently existing Rust code!) be considered a representative sample? I'm guessing, though I don't have knowledge, that web browser engines written in C++ also use placement new a lot. But I'd also think that if you consider all C++ code in existence, you would find that it's used pretty rarely. (Of course, C++ /does/ reserve the keyword. But presumably not for the reason that placement new is super-common.) We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. That flavor is much of the reason for Rust's reputation as an overly complex language. I really like the way current Rust thinks of the various sigils as just another constructor. I also like the consistency with other major languages of `new`, so I'm conflicted. And yes, the constructor-like property seems unfortunately difficult to extend to third-party smart pointers... but in general I really don't like the solution to $thing is not as convenient with third-party types as with the built-in ones being to make it equally inconvenient for the built-in ones. Now you have two problems. I think the complexity you mention is an inherent part of the semantics of Rust. The most intuitive and ergonomic way to expose it to the programmer is a very important consideration, but you're still not doing more than pushing the complexity around. Basically, I'm not sure Rust's reputation as a complex language is something you could cause to go away in this fashion. If you replace all of the sigils with explicit `FooT` and `new` syntax, will that make people see it as less complex? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 sum up the way I feel. We're blazing new language design trails here in Rust, and anything we pick is going to feel a bit uncomfortable. I tend to want to err on the side of a little verbosity if it makes the most unfamiliar parts of Rust feel more intuitive. But verbosity must of course be used sparingly... Patrick Gábor Lehel illiss...@gmail.com wrote: 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 that. Placement new is not going to be used rarely. In Servo, for example, it's used all over the place. Can that (or even the totality of currently existing Rust code!) be considered a representative sample? I'm guessing, though I don't have knowledge, that web browser engines written in C++ also use placement new a lot. But I'd also think that if you consider all C++ code in existence, you would find that it's used pretty rarely. (Of course, C++ /does/ reserve the keyword. But presumably not for the reason that placement new is super-common.) We've been moving stuff from the language into the libraries, yes. But losing ~ seems like losing a big part of the flavor of Rust, so to speak. That flavor is much of the reason for Rust's reputation as an overly complex language. I really like the way current Rust thinks of the various sigils as just another constructor. I also like the consistency with other major languages of `new`, so I'm conflicted. And yes, the constructor-like property seems unfortunately difficult to extend to third-party smart pointers... but in general I really don't like the solution to $thing is not as convenient with third-party types as with the built-in ones being to make it equally inconvenient for the built-in ones. Now you have two problems. I think the complexity you mention is an inherent part of the semantics of Rust. The most intuitive and ergonomic way to expose it to the programmer is a very important consideration, but you're still not doing more than pushing the complexity around. Basically, I'm not sure Rust's reputation as a complex language is something you could cause to go away in this fashion. If you replace all of the sigils with explicit `FooT` and `new` syntax, will that make people see it as less complex? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 maybe we can think of a better naming convention for constructors... perhaps `foo::make()`. Honestly, `new` seems ideal here. Easier to type than `~` and easier on the eyes than `alloc`. The only argument that I can think of against it would be if its semantics are different enough from C++ that it would cause more confusion than it alleviates. On Sat, Nov 30, 2013 at 4:54 PM, Patrick Walton pcwal...@mozilla.comwrote: 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 is to say that trying to piggyback on C++ programmers' familiarity of `new` is actually a really bad idea, as Rust's allocation operator differs in a few important ways from C++. In fact, offhand I can't think of any language with a `new `operator that uses it for something other than invoking a class constructor. Well, there aren't many languages with allocation operators period: the vast majority of languages implicitly allocate on the heap. Of those languages with an allocation operator that isn't a function, it's universally `new` as far as I know. 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 + 2)` being weird: it's that I'm more concerned about what's not going to make C++ programmers run away. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 hidden return pointer is set to the newly allocated location. Patrick Gábor Lehel illiss...@gmail.com wrote: On Sat, Nov 30, 2013 at 10:26 PM, Patrick Walton pcwal...@mozilla.comwrote: 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 using Path(..) is better than Path::init(..)). Honestly, I'm not in love with `init` either. I don't find it particularly intuitive, and alternatives are welcome. But I do think that using a sigil for allocation and the lack of placement new are problems that needs fixing. Pretty basic question, but: what does placement new in a Rust context even mean, precisely? The very same thing as in C++? Because in C++ allocation and placement new are pretty orthogonal. If you write `new Foo`, it means: allocate memory for a Foo and run its constructor in that memory. If you write `new (foo) Foo`, it means: *don't* allocate memory, just construct a Foo directly into `foo`, which is some existing piece of memory I provide. So while `new` is the allocation operator, placement new is in fact just a funny syntax for running constructors. Which I think is confusing as heck. All of that leading up to: if these are different things, mightn't it make sense for Rust to use different syntax for them? (And if placement new in Rust is different from placement new in C++, then what's the difference?) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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* a shame that `foo::new()` has to change, but `alloc` is much grosser than `init`. And maybe we can think of a better naming convention for constructors... perhaps `foo::make()`. FWIW, in Objective-C: [MyType new] is shorthand for [[MyType alloc] init] (Not saying we should do the same, just some prior art.) -- Your ship was destroyed in a monadic eruption. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 convention. Patrick Benjamin Striegel ben.strie...@gmail.com wrote: 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 maybe we can think of a better naming convention for constructors... perhaps `foo::make()`. Honestly, `new` seems ideal here. Easier to type than `~` and easier on the eyes than `alloc`. The only argument that I can think of against it would be if its semantics are different enough from C++ that it would cause more confusion than it alleviates. On Sat, Nov 30, 2013 at 4:54 PM, Patrick Walton pcwal...@mozilla.comwrote: 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 is to say that trying to piggyback on C++ programmers' familiarity of `new` is actually a really bad idea, as Rust's allocation operator differs in a few important ways from C++. In fact, offhand I can't think of any language with a `new `operator that uses it for something other than invoking a class constructor. Well, there aren't many languages with allocation operators period: the vast majority of languages implicitly allocate on the heap. Of those languages with an allocation operator that isn't a function, it's universally `new` as far as I know. 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 + 2)` being weird: it's that I'm more concerned about what's not going to make C++ programmers run away. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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...) Old Rust used to use mk as the constructor convention. Patrick If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. Regards, Florian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 indifference, but `box` really makes sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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, we have plenty of other non-alphabetic operators that don't cause confusion, why is this one special? That said, of all the alternative proposals, `box` seems the most sensible to me. -Kevin On Nov 30, 2013, at 5:54 PM, Corey Richardson co...@octayn.net wrote: 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 indifference, but `box` really makes sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 inherent problems with using a non-alphabetic symbol as an operator. Heck, we have plenty of other non-alphabetic operators that don't cause confusion, why is this one special? I'll admit, I don't find the confusing argument very convincing. I just think `box` looks better than `~`. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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: On 11/30/13 6:49 PM, Corey Richardson wrote: 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 inherent problems with using a non-alphabetic symbol as an operator. Heck, we have plenty of other non-alphabetic operators that don't cause confusion, why is this one special? I'll admit, I don't find the confusing argument very convincing. I just think `box` looks better than `~`. I'm warming up to this idea -- `box 10` does make more sense than `new 10`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving `new` as a keyword? Here's a few random ideas (where val is the value expression and place is the place expression): ~in(place) val in(place) ~val ~val in place (assuming this isn't somehow ambiguous) ~~val in place (the existing ~~val would have to be written ~(~val)) ~~(place) val (the existing ~~val would have to be written ~(~val)) ~place val ~=place val ~place val(this looks like an arrow pointing to the place) ~(place) val Personally I think `~in(place) val` is perfectly fine. It's not the prettiest of syntaxes, but placement new should be very rare, and this allows us to avoid reserving `new` and continue to use ~ as the allocation operator. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
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 exposed to that syntax from another language, one that actually documents the fact that it allocates. Users who haven't been exposed to `new Foo` from other languages will have no reason to understand that this allocates without being told that it allocates. As such, there is no reason why we cannot simply fix the documentation to explain that `~` is the allocation operator, and that when it's used in an expression it means it allocates a value. It was then explained to me that the real reason we needed `new` wasn't because of the issues with users understanding allocation, but because of a need for placement new. That is why I suggested some alternative syntaxes. Also, FWIW, `~(n + m)` makes sense, as a way of producing an allocated value from the result of `n + m`, but `new (n + m)` is pretty nonsensical. -Kevin On Nov 29, 2013, at 10:48 PM, Patrick Walton pwal...@mozilla.com wrote: None of these look like allocation. Patrick Kevin Ballard ke...@sb.org wrote: I am very saddened by the fact that we're apparently reserving `new` as a keyword, and even more by the fact that the proposed placement new syntax is `new(foo) bar`. This looks exactly like C++, and it goes against the strong precedence we already have of using new() as a static function for types. Path::init(foo) looks extremely wrong to me. Surely there's another syntax we can use for placement new that doesn't involve reserving `new` as a keyword? Here's a few random ideas (where val is the value expression and place is the place expression): ~in(place) val in(place) ~val ~val in place (assuming this isn't somehow ambiguous) ~~val in place (the existing ~~val would have to be written ~(~val)) ~~(place) val (the existing ~~val would have to be written ~(~val)) ~place val ~=place val ~place val(this looks like an arrow pointing to the place) ~(place) val Personally I think `~in(place) val` is perfectly fine. It's not the prettiest of syntaxes, but placement new should be very rare, and this allows us to avoid reserving `new` and continue to use ~ as the allocation operator. -Kevin Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
