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 <andrew...@gmail.com 
> <javascript:>> 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.
>>
>
>

Reply via email to