# Ambiguity on Vector{\<:Abstract\*}?
**URL:** https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586
**Category:** General Usage
**Created:** [April 27, 2018, 10:00pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586 "2018-04-27T22:00:38Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 27, 2018, 10:00pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/1 "2018-04-27T22:00:38Z")
this may fit better in development than first steps, but before I bother the developers, let me ask the basics?
would it introduce any ambiguity if `Vector{AbstractFloat}` was interpreted as `Vector{<:AbstractFloat}`.
The former seems quite natural, and I have been bitten a few times by inadvertently forgetting the `<:` .
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 27, 2018, 10:22pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/2 "2018-04-27T22:22:36Z")
Julia’s type parameters are “invariant.” Your suggestion would make them “covariant.” In short: that’s a major design change.
One place invariance is crucial is that Julia uses a different memory layout for `Vector{Any}`, `Vector{Union{Int, Missing}}` and `Vector{Int}`, with the latter two being much more optimized. The only way this could possibly work is if Julia can reason about those three types independently from each other. The same goes for custom parametric structs.
This is a whole big thing in computer science. This wiki article is long, but it’s actually not completely terrible—especially if you jump straight to the Array section.
> **[Covariance and contravariance (computer science)](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science))**
>
> Many programming language type systems support subtyping. For instance, if the type Cat is a subtype of Animal, then an expression of type Cat should be substitutable wherever an expression of type Animal is used.
> Variance is how subtyping between more complex types relates to subtyping between their components. For example, how should a list of Cats relate to a list of Animals? Or how should a function that returns Cat relate to a function that returns Animal?
> Depending on the variance of the ...
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 11:03pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/3 "2018-04-27T23:03:34Z")
No, because they are two distinct concepts, and you need a way to express both.
This comes up a lot. Probably would make a good blog post to explain the motivation in more detail
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 11:06pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/4 "2018-04-27T23:06:00Z")
See, for example, this post: [Problem with Complex{Rationals} - #7 by stevengj](https://discourse.julialang.org/t/problem-with-complex-rationals/9474/7)
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 28, 2018, 3:16am UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/5 "2018-04-28T03:16:24Z")
thanks. understood.
to understand most easily what would be lost by automatic recognition, can someone please give me an example of what call
```julia
function f(x::Vector{AbstractFloat}); 2; end
```
catches at the moment?
regards,
/iaw
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [April 28, 2018, 5:49am UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/6 "2018-04-28T05:49:16Z")
It catches a `Vector{AbstractFloat}`, just like it says:
```julia
julia> x = Vector{AbstractFloat}(5)
5-element Array{AbstractFloat,1}:
#undef
#undef
#undef
#undef
#undef
julia> f(x)
2
```
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 28, 2018, 2:55pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/7 "2018-04-28T14:55:25Z")
thanks. this explains it. I did not realize that an object could be of type AbstractFloat. I thought AbstractFloat was more like an enumeration of possible types of an object, but one that could not be the type of an existing object.
```julia
julia> x=AbstractFloat(3)
3.0
julia> typeof(x)
Float64
```
This was my misunderstanding.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 28, 2018, 3:03pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/8 "2018-04-28T15:03:28Z")
> [@iwelch](#):
>
> I did not realize that an object could be of type AbstractFloat.
No, an object cannot be of type `AbstractFloat`, because `AbstractFloat` is an abstract type — objects can only have concrete types.
If you have `Vector{AbstractFloat}`, each element is a concrete floating-point type, but the elements can of be _different_ concrete types:
```julia
julia> a = AbstractFloat[1.0, 2.0f0, big(3.0)]
3-element Array{AbstractFloat,1}:
1.0
2.0
3.000000000000000000000000000000000000000000000000000000000000000000000000000000
```
Physically, this means that the elements of `a` must be stored as pointers to “boxes” that contain the value along with a type tag, in order to store the fact that `a[1]` is a `Float64`, `a[2]` is a `Float32`, and `a[3]` is a `BigFloat`. Such an array is very flexible in that it can store different types, but processing it is inherently slow. For example, if you compute `sum(a)`, when _every_ element is added it needs to (1) chase an extra pointer to the box, (2) look at the type tag, (3) dispatch at runtime to the correct `+` function for that type of `AbstractFloat`, and (4) store the result of the summation in a “box” as well because the type of the result can only be determined at runtime too.
In contrast, for a `Vector{Float64}`, every element is of the same type, so the `Float64` type tag can be attached to the array as a whole, not the individual elements. Hence the elements can be stored as 64-bit values one after the other consecutively in memory. Something like `sum` just loads these values one at a time into a register and sums each with one machine instruction that was determined at compile-time, not at runtime.
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 28, 2018, 3:08pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/9 "2018-04-28T15:08:35Z")
yep. this is exactly what I had missed.
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 28, 2018, 4:03pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/10 "2018-04-28T16:03:05Z")
if Julia had “compiler warning” settings, it would be good if it emitted a notice [\<;warning ;-)) that the use of `Vector{...}` is much rarer than `Vector{<:...}` (where … are a couple of common types, like AbstractFloat, Real, etc.). This is probably a common beginner’s error, and would reduce novice pain.
---
### Author:  [@jlperla](https://discourse.julialang.org/u/jlperla)
#### Post date: [April 28, 2018, 4:30pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/11 "2018-04-28T16:30:35Z")
I have to the conclusion that for beginners, the less type annotations the better. Let the compiler figure things out on its own, and let library writers worry about making sure all of the mathematics on the generic types are sound.
See [Is a simple, beginner style with named parameters and no unnecessary type annotations acceptable?](https://discourse.julialang.org/t/is-a-simple-beginner-style-with-named-parameters-and-no-unnecessary-type-annotations-acceptable/8917) and discussion.
---
### Author:  [@iwelch](https://discourse.julialang.org/u/iwelch)
#### Post date: [April 28, 2018, 4:59pm UTC](https://discourse.julialang.org/t/ambiguity-on-vector-abstract/10586/12 "2018-04-28T16:59:45Z")
> [@jlperla](#):
>
> the less type annotations the better.
not my conclusion. it is _less_ confusing until there is a bug, and then it is _more_ confusing. of course, it will also create more bugs, too. then again, it means that novices understand less than they may need to (although often they never need to understand it, in which case we should have indeed spared them.)
it is a tradeoff, where reasonable people come to different conclusions. De gustibus non est disputandum. I am just glad that both are possible.