But maybe it is if the output type is specified as well as in the OP?
julia> function g()::Vector{Float64}
y = [1.0, 2.0]
y = [1, 2]
y
end
g (generic function with 1 method)
julia> g()
2-element Vector{Float64}:
1.0
2.0
julia> function f()::Vector{Float64}
y::Vector{Float64} = [1.0, 2.0]
y = [1, 2]
y
end
f (generic function with 1 method)
julia> f()
2-element Vector{Float64}:
1.0
2.0
I wouldn’t use a type annotation on extra collected keyword arguments. For example:
foo(;kwargs...)::Bool = :foo in keys(kwargs)
I’m not sure if it is even possible to add a type annotation for kwargs here.
There is no denying that sometimes in simple functions the annotation in the function signature is repeated in a variable annotation. This happens in any function that does not all another if a variable is returned. Then the added value of annotation is only that the type is fixated.
No, that’s only because [1, 2] is being converted to Vector{Float64} on the assignment to y. Try with ['a', 'b'].
I just want to point out that
x = foo()::T
and
x::T = foo()
are different and you should be aware of this.
The first one simply checks that the output of foo() is a T before assigning it to x.
The second one performs a conversion before assigning to x and is equivalent to
x = convert(T, foo())::T
Similarly
function bar()::T
return foo()
end
and
function bar()
return foo()::T
end
are different. The first one inserts a convert and is equivalent to
function bar()
return convert(T, foo())::T
end
Edit: I’m pointing this out because those extra non-explicit converts can be a performance footgun. If they are part of a style guide, anyone following the guide should be aware of this.
One aspect I would like to highlight here is the difference between making a type assertion at the function definition versus the return statement.
convert, and maybe throw an error if conversion fails.throw a TypeError.julia> foo(x)::Int = x
foo (generic function with 1 method)
julia> bar(x) = x::Int
bar (generic function with 1 method)
julia> foo(5)
5
julia> bar(5)
5
julia> foo(5.0)
5
julia> bar(5.0)
ERROR: TypeError: in typeassert, expected Int64, got a value of type Float64
julia> foo(5.5)
ERROR: InexactError: Int64(5.5)
julia> bar(5.5)
ERROR: TypeError: in typeassert, expected Int64, got a value of type Float64
Do you plan to allow any polymorphism? i.e. any abstract types?
If you want concrete static types for everything, I’m curious — why are you using a dynamic language like Julia? Is it because of some packages/features you want to use, or because you want to do prototyping with dynamic code and then add static annotations for production, or?
No wrong answers here, I’m just wondering what the appeal of Julia is vs. a statically typed language (C++, Rust, …) in this kind of context.
julia> f(x::Vector{Float64}) = x
f (generic function with 1 method)
julia> x::Vector{Float64} = rand(3);
julia> y::Vector{Float64} = @view x[1:2]
2-element view(::Vector{Float64}, 1:2) with eltype Float64:
0.24973421955571018
0.29731016911412356
julia> f(y)
2-element Vector{Float64}:
0.24973421955571018
0.29731016911412356
julia>
The performance advantage of using a view on the caller side is lost, but the workaround is simple.
The second one performs a conversion before assigning to
xand is equivalent > tox = convert(T, foo())::T
Perhaps you meant this?
x::T = convert(T, foo())
Afaik, the return value of convert is already of type T and it does not need to be asserted. The difference is important for the discussion as x::T guarantees that x will not change type until it goes end of scope.
Indeed, convert may be called. It is only called though when there is something to convert. A function annotated with ::S returning a local variable of type S will not induce a call to convert. So the performance hit is absent in this case. We expect that developers will not introduce a lot of convert methods for other cases.
julia> import Base.convert
julia> struct S
mem::Int64
end
julia> function convert(::Type{S}, x::Any)::S
println("convert(...): Started.")
return S(x)
end
convert (generic function with 196 methods)
julia> function return_right_type(s::S)::S
return S(s.mem * s.mem)
end
return_right_type (generic function with 1 method)
julia> u::S = return_right_type(S(42))
S(1764)
julia> v::S = 5
convert(...): Started.
5
julia>
Julia was selected for performance first and secondly, engineers with relatively little programming experience can start prototyping in Julia. What we are seeing now is that the code base is becoming harder and harder to maintain as our internal Julia community grows. Type annotations typically are performance neutral and improve understandability of the code - especially when there are many, many structs.
Only in some cases. Relevant issue:
julia> struct S end
julia> Base.convert(::Type{S}, ::Any) = 3
julia> convert(S, 7)
3
As possibly the biggest fan of type assertions among the users here: 
Why would you annotate the variable as Vector, let alone Vector{Float64}? This almost surely serves no purpose and is actively harmful.
Type annotations can be good. They’re basically machine checked internal documentation, for checking necessary invariants. Also they may help type inference in some cases.
However in your case, as others have already indicated, the type annotations are pointless and harmful.
NB: in case this wasn’t mentioned already, a type annotation on a variable doesn’t just type assert, it also calls convert. Almost always (or always, if you’re making a style guide…) you should prefer to put the type annotation on the RHS.
To make my criticism more constructive, I’d propose a style guide like so:
@nospecialize or to force specialization. Consult the Performance tips page in the Manual.MethodError in dispatch is preferable to an exception being thrown later in the method body, so do use type annotations if this just helps you get an error earlierThis recent feature request on the Julia Github repo is relevant to Julia style (guides):
Keep an eye on the implementation status, and possibly adopt suggestions from the issue comments into the style guide as you see fit.
There you a just converting the view into a newly allocated vector. That’s just a workaround for the limitation of the interface, and defeats the purpose of the view.
In parallel: you mention large structs and long functions. The former can and should be strictly type annotated, nobody disagrees. The later should be avoided, they are a maintenance nightmare with or without strict types.
Yeah, but in the case of Ints both end up getting converted so there is seemingly little benefit to using both. As for strings
julia> function f()
y::Vector{Float64} = [1.0, 2.0]
y = ["a","b"] # errors here
y
end
f (generic function with 1 method)
julia> f()
ERROR: MethodError: Cannot `convert` an object of type String to an object of type Float64
julia> function g()::Vector{Float64}
y = [1.0, 2.0]
y = ["a","b"]
y # errors here
end
g (generic function with 1 method)
julia> g()
ERROR: MethodError: Cannot `convert` an object of type String to an object of type Float64
One errors on the internal reassignment, and one errors on conversion before returning, but in both cases future type instabilities are prevented by only allowing return values of Vector{Float64}. Also, both versions are flagged by @code_warntype as having y::Union{Vector{Float64}, Vector{Int64}}. Again, where this happens is differs, but the core result – having a Union type – is the same.
That’s really what I meant by redundant, not that they are exactly identical in practice, but that they both provide the same level of type stability with regards to the output.
As an aside, @code_warntype is not always entirely truthful. But here, it is true that the name y can have either of those types across the entire life of the function. However, here there is no ambiguity as to what it is at any particular time. And the @code_warntype does clearly show that it knows the return value is a Vector{String}.
A variable is not a place in memory, so a variable that takes multiple types does not need to be able to store and interchange those types arbitrarily. It is simply a name (“binding”) that you can use to refer to some datum. Just because I can put a surfboard in my car for one trip and a snowboard in my car for another doesn’t mean I can’t know which it holds at any given time.
julia> @code_typed g()
CodeInfo(
1 ─ %1 = Core.tuple("a", "b")::Tuple{String, String}
│ %2 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{String}, svec(Any, Int64), 0, :(:ccall), Vector{String}, 2, 2))::Vector{String}
└── goto #7 if not true
2 ┄ %4 = φ (#1 => 1, #6 => %13)::Int64
│ %5 = φ (#1 => 1, #6 => %14)::Int64
│ %6 = Base.getfield(%1, %4, false)::String
│ Base.arrayset(false, %2, %6, %4)::Vector{String}
│ %8 = (%5 === 2)::Bool
└── goto #4 if not %8
3 ─ goto #5
4 ─ %11 = Base.add_int(%5, 1)::Int64
└── goto #5
5 ┄ %13 = φ (#4 => %11)::Int64
│ %14 = φ (#4 => %11)::Int64
│ %15 = φ (#3 => true, #4 => false)::Bool
│ %16 = Base.not_int(%15)::Bool
└── goto #7 if not %16
6 ─ goto #2
7 ┄ goto #8
8 ─ return %2
) => Vector{String}
Not only is there no ambiguity, Float64 never even appears here because it’s part of dead code that gets eliminated.
It’s hard to imagine that no one at your company will ever want to call the same code with different types. What about a function that finds the smallest positive value in a collection? Do you really want people to write multiple versions of that function that are explicitly annoted to operate on each of Vector{Float64}, Vector{Int64}, SVector{3,Float64}, and SubArray{Float64, 1, Matrix{Float64}, Tuple{UnitRange{Int64}, Int64}, true}? And what if they recognize a bug and fix it in most of those, but accidentally miss one where it persists for goodness-knows how long? That’s where maintainability really starts to crumble. There’s even a principle for this in software engineering. This proposal is not entirely maintainability up-side.
A few strategically-placed comments at confusing places are much more informative than exhaustive (and exhausting) annotation. Types are usually the least interesting part of code anyway – what/why/how the code does things is the part that’s actually important to communicate.
As commenters indicated above, a RHS type annotation is actually a stronger assertion than one on the LHS, because a LHS annotation will attempt to convert the value and only throw if that fails. The RHS annotation will fail without recourse if it is mislabeled. So requiring all RHS to be annotated would result in stricter typing requirements than LHS. Besides, it sounds like your proposal is to require annotations on every LHS so it’s not like it’s fewer annotations than RHS would be.
julia> x1::Int = 3.0
3.0
julia> x2 = 3.0::Int
ERROR: TypeError: in typeassert, expected Int64, got a value of type Float64
If you are too onerous to your users and fail to provide aggressive supervision, they can simply satisfy the letter (but not spirit) of your requirements by annotating every variable ::Any
function h()
y::Any = 4.0
return y
end
And yet, despite the ::Any (or a ::Real) annotation, the @code_warntype is not fooled and knows y is specifically a Float64. These ::Any annotations are harmless and effectless except for adding work for the parser and compiler.
More like anno-y-tation, amirite?
(Sorry I’ll see myself out)
Julia is not C.
While one should be able to code like this and we should provide conveniences to support this, I am not sure if I would recommend this as part of company-wide style guide.
As many have noted above, these are not merely annotations but also have consequences that could be harmful in several ways including negatively impacting performance, reducing reusability, and throwing errors you did not intend to throw.
In particular, I recommend focusing more on right side assertions than left side assertions. Left hand side assertions can result in implicit conversions as noted above. While implicit conversions can be useful, they can occur at long distances from where the type annotation was created. This really should be done with intention and not due to style. Right hand side type assertions do not involve conversion but merely make the statement that a variable or return value should be of a certain type. That’s usually what I want and is stricter. If conversions need to happen, they should probably be explicitly done and their results should be asserted as well.
I also recommend the use of type parameters in this case. They would help to increase reusability but also help show how types are related.
function f(value::T, obj::MyStruct) where T
vec = T[1.0, 2.0, 3.0]
other = calculate_other_struct(value::T, obj::MyStruct, vec::Vector{T})::OtherStruct
return other::OtherStruct
end
For some functions in very specific contexts, this may be appropriate. In a general context, over annotating can result in less flexible and more fragile code. Type assertions invite potential unintended runtime errors even when the unasserted code would have run perfectly fine. In many cases, you really only want such errors to occur only during analysis and not runtime.
Where I think type assertions would be most useful are return statements. This helps to enforce the interface of a function and makes other type assertions unnecessary.
Can you clarify this? If any function is type annotated, the conversion happens upon return.
Also, I fail to see how performance is negatively impacted. If there is nothing to convert, convert is not called, see above. The proposal is to add the annotations that would otherwise be inferred. A very big advantage of annotation of variables is that the type can not change any more for the lifetime of the variable.