The expression y = int64(4) returns its right hand side, not the value of y. If you add an explicit `return y` after that, it does what you expect.
On Wed, Jun 4, 2014 at 1:22 AM, Andrew Simper <[email protected]> wrote: > All good here, you were polite and to the point and it is easy to work > around. Basically I took from the replies: > > Jameson: that is a redundant thing to do since that case is already > handled another way > Stefan: yes, but it is inconsistent since inside functions this same > syntax is recommended for efficiency so we should really fix this when we > have time > > Ok, I think I've found the problem of my confusion, and it stems from my > interpretation of this document: > > http://julia.readthedocs.org/en/latest/manual/types/ > > When appended to a *variable* in a statement context, the :: operator > means something a bit different: it declares the variable to always have > the specified type, like a type declaration in a statically-typed language > such as C. Every value assigned to the variable will be converted to the > declared type using the convert function: > > But "always" seems like too strong a word to use (at least not as of > v0.3.x) since this happens: > > > <https://lh6.googleusercontent.com/-k6nxq7zpvIY/U46ZDhgBY3I/AAAAAAAAANQ/dVF1AIH0s_0/s1600/Screen+Shot+2014-06-04+at+11.53.32+AM.png> > So with this type of behaviour I can see why using the ::Float64 type > definition at the global scope is problematic, since at any time anyone > could change the type, whereas in the local scope you know all the > operations on the variable and the order they are happening in so you know > at each line what the type will be. > > What is the use case of locking down the type to something temporarily and > then allowing it to be changed it again? This could lead to all sorts of > programmer errors. If there is such a use case then is there another way to > handle it? If the type of a variable declared with syntax ::TypeName is > locked down from changing then such declarations done globally could be > more easily handled, and local declarations could be more aggressively and > easily optimised as well since the compiler knows they will always refer to > a fixed type. > > > > > On Wednesday, June 4, 2014 11:18:48 AM UTC+8, Stefan Karpinski wrote: > >> I hope you didn't interpret that as dismissive – it would be good to have >> this fixed. >> >> >> On Tue, Jun 3, 2014 at 11:09 PM, Andrew Simper <[email protected]> >> wrote: >> >>> >>> On Wednesday, June 4, 2014 10:32:43 AM UTC+8, Stefan Karpinski wrote: >>>> >>>> I do think it would be a good thing to fix, however. It's just not as >>>> pressing as other issues. >>>> >>>> >>> Yep, I completely understand, please get on with the more important >>> stuff. >>> >>> Hopefully any other c / c++ programmers will get to read this thread and >>> not have to interrupt you again about this quirk. >>> >> >>
