Use of a decimal point to show Floats ambiguous

[IainNZ]

type Vec
x::Float64
y::Float64
z::Float64
end

a = Vec(1., 2., 3.)
_(a::Int64, b::Vec) = Vec(a_b.x, a_b.y, a_b.z)
_(a::Float64, b::Vec) = Vec(a_b.x, a_b.y, a_b.z)

println(1_a)
println(2.5_a)
println(1.a) # This line fails with ERROR: no method .(Int64,Vec)

[JeffBezanson]

There doesn't seem to be a definition of .*

[IainNZ]

Right good point. I guess my confusion stems from how it often seems to be acceptable to use 1. to mean a Float, but here that breaks down. Confusing behaviour?

[mlubin]

This could be a tricky point for beginners, but I think it's worth it to be able to use 1. as a float constant.

[JeffBezanson]

We deliberately decided to resolve the ambiguous case 1.*x as 1 .* x, since if x is float it makes basically no difference, but if x were integer we wouldn't want 1.*x to spuriously promote to float.

[johnmyleswhite]

One thing we could do to make this a little better is to put a comment in the style guide advocating whitespace around operators, which is what Google partially recommends for languages like Python and R: https://google-styleguide.googlecode.com/svn/trunk/pyguide.html

This won't resolve the issue, but discourages ambiguity.

[tomasaschan]

Isn't there an ambiguity warning that could be issued here? I do agree that the current behavior makes sense, but printing a warning message that this is ambiguous, and that it's better to write either 1. * x or 1.0 * x to avoid the ambiguity, would be very helpful.