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
