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" <[email protected]> wrote:
>On Sat, Nov 30, 2013 at 10:17 PM, Patrick Walton
><[email protected]>wrote:
>
>> 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 `Foo<T>` and `new` syntax, will that make
>people
>see it as less complex?
>
>
>>
>> Patrick
>>
>> _______________________________________________
>>
>> Rust-dev mailing list
>> [email protected]
>> 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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
