What ML does differently is having the syntax of let bindings
explicitly introduce a new scope by being terminated with 'in' - e.g.
you'd say
let test = test () in
println (format! ("{}", test));
which would make the behaviour unsurprising.
martin
On Wed, Nov 13, 2013 at 10:13 AM, Brendan Zabarauskas
<[email protected]> wrote:
> SML also shares these semantics when it comes to bindings. That is, a
> subsequent binding to the same identifier can ‘mask’ those that proceed it,
> even if they are in the same scope and the bound values are of different
> types. Once a value has had its identifier masked, it can no longer be
> accessed.
>
> I assume this behaviour was passed on to Ocaml, and Rust inherited it from
> there. Rust was originally written in Ocaml, and has drawn many influences
> from there. I personally find it useful from time to time.
>
> ~Brendan
>
> On 14 Nov 2013, at 3:25 am, Joshua Rodgers <[email protected]> wrote:
>
>> I'm curious as to why this is valid, though? This makes sense if you're
>> inside a new or nested scope, but why is it valid inside the same scope as
>> illustrated in the code example?
>>
>> I can understand it from the perspective that I need to mask a function name
>> (but that's a nested scope to me, at that point).
>>
>>
>> On Wed, Nov 13, 2013 at 8:54 AM, Scott Lawrence <[email protected]> wrote:
>> I would think that `test()` (the function) is in scope for the duration of
>> `let test =`, and then the new definition masks the old one. Similarly,
>>
>> let x = 2;
>> let x = x + 2;
>>
>> If you change the last line to /call/ test(), you should get an error.
>>
>>
>> On Wed, 13 Nov 2013, Philip Herron wrote:
>>
>> Hey all
>>
>> I am still learning but i just tried something which i expected to give an
>> error but works:
>>
>> fn test () -> int {
>> 1
>> }
>>
>> fn main () {
>> let test = test ();
>> println (format! ("{}", test));
>> }
>>
>> I guess on compilation the names are mangled against their types or
>> something so you can differentiate between test the function and test the
>> variable. Not sure would be nice to get some clarification what this
>> behavior is.
>>
>> Thanks
>>
>> --Phil
>>
>>
>> --
>> Scott Lawrence
>> _______________________________________________
>> Rust-dev mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>> _______________________________________________
>> Rust-dev mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
