`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 `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
