On type annotations

New to Julia
82

To be absolutely clear, erroring at declaring another local variable of the same name does not involve the annotations at all:

julia> function foo(x)
        local x
       end
ERROR: syntax: local variable name "x" conflicts with an argument

It’s very clearly documented that argument annotations serve multiple dispatch. Nowhere does it say that it restricts the type of instances assigned to a variable. I would argue that would be needlessly restrictive. Say you have a function foo that takes in either a x::Int or x::Float64, and x could switch types in the body x = bar()::Union{Int, Float64}. However, you need to dispatch to separate methods depending on what type the input x is. If the argument annotation restricted x’s type, it’s impossible to pull this off.

2 Likes
83

Regardless whether it’s considered a bug it would be quite breaking to change and not really an option before 2.0. It could be a candidate for the mechanism proposed in Add `strict` mechanism for opting into stricter subsets of the language · Issue #54903 · JuliaLang/julia · GitHub though.

4 Likes
84

Actually, what is the reason of not allowing introducing const within a local scope like a function definition?

1 Like
85

See implement local const · Issue #5148 · JuliaLang/julia · GitHub

2 Likes
86

I’m prototyping a macro to get rid of the conversions here:

julia> @noconvert function foo(x::Number)
           let x::Int = x
               x
           end
       end
foo (generic function with 2 methods)

julia> foo(3)
3

julia> foo(3.0)
ERROR: TypeError: in typeassert, expected Int64, got a value of type Float64

julia> foo(3.5)
ERROR: TypeError: in typeassert, expected Int64, got a value of type Float64

The code generation looks pretty clean:

julia> @code_llvm foo(3)
;  @ none within `foo`
define i64 @julia_foo_1572(i64 signext %0) #0 {
top:
  ret i64 %0
}

julia> @code_llvm foo(3.0)
;  @ none within `foo`
; Function Attrs: noreturn
define void @julia_foo_1574(double %0) #0 {
top:
  call void @j_overdub_1576(double %0) #6
  unreachable
}
2 Likes
87

An exception where variable type declarations are useful is when the variable will be captured by a closure and assigned to in the closure. Currently this leads to bad type inference for that variable unless it has a type declared.

88

That doesn’t necessarily solve the problem.

function foo()
    x::Int64     = 1
    x            = 1

    bar()::Int64 = x::Int64
    
    return bar()
end

@code_warntype foo()            # type UNSTABLE
89

There’s some red in there, because of boxing, but the return type is precisely inferred due to the type declaration.

Compare foo1 and foo2:

function foo1()
    x = 1
    x = 2
    function bar()
        x = 3
        x
    end
    bar()  
end
function foo2()
    x::Int = 1
    x = 2
    function bar()
        x = 3
        x
    end
    bar()
end
@code_warntype foo1()
@code_warntype foo2()
1 Like
90

Yes, my point is that closures can lead to unexpected behavior, and depending on where you add the type annotation, you don’t necessarily solve the problem. I was just adding a word of caution about using type annotations as a silver bullet for type inference in closures. But, yeah, in the example I provided, the issue won’t arise.

1 Like