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
>>>> 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
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
