Come to think of it, it might also make the grammar for function signatures
ambiguous, given that we allow null return types to be omitted.
On Mon, Jul 29, 2013 at 9:18 PM, Benjamin Striegel
<ben.strie...@gmail.com>wrote:
> I don't agree that the type of a function and the return type of a
> function are the same thing (specifically, the type of the function
> contains the return type). :) If nothing else, this would make the function
> signatures of higher-order functions much harder to read IMO.
>
>
> On Mon, Jul 29, 2013 at 8:29 PM, Patrick Walton <pwal...@mozilla.com>wrote:
>
>> On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
>>
>>> Hi,
>>>
>>> I'm observing rust development for some time, and I must say it slowly
>>> encourages me to use it. Especially the progress from Perl-like syntax
>>> to more sane and quiet form is enjoyable.
>>> That said I wonder why the function definition has form:
>>> fn name(var: type, ...) -> return_type {...}
>>> instead of more unified:
>>> fn name(var: type, ...): return_type {...}
>>>
>>> Is it constructed to mimic mathematical form f(x)->y or is there other
>>> reason i.e. syntax ambiguity?
>>>
>>
>> Personal preference of Graydon, I believe. This is one of the few
>> decisions that has survived from Rust 0.1 :)
>>
>> I slightly prefer `:` to `->` but never enough to bring it up.
>>
>> Patrick
>>
>>
>> ______________________________**_________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>>
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
