# Is a more specialized element type of unique() a breaking change?

**URL:** <https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003>\
**Category:** Internals & Design\
**Created:** [August 24, 2018, 4:26pm UTC](https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003 "2018-08-24T16:26:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)\
**Post date:** [August 24, 2018, 4:26pm UTC](https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003/1 "2018-08-24T16:26:59Z")

</div>

I’m working on [https://github.com/JuliaLang/julia/pull/28737](https://github.com/JuliaLang/julia/pull/28737) to educate myself and have now come to a point where I’m wondering if a more specialized return type of the function `unique` would be a problem.

Current behaviour taken from a unit test:

```julia
unique(x for x in Any[1, 1.0])::Vector{Real} == [1]

```

Would it be okay to have it like this:

```julia
unique(x for x in Any[1, 1.0])::Vector{Int64} == [1]
unique(x for x in Any[1, 1.1])::Vector{Real} == [1,1.1]

```

?

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [August 25, 2018, 1:09am UTC](https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003/2 "2018-08-25T01:09:26Z")

</div>

Is that Syntex free?

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [August 25, 2018, 1:22am UTC](https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003/3 "2018-08-25T01:22:44Z")

</div>

It’s not a “more specialized return” (changing return value from `Real` to `Int`, i.e. narrowing down the possible types to return is more specialized return), it’s just changing the return type. So yes it is breaking, a possibly minor one, but breaking nonetheless.

It’s also unclear though why you want to make a function more type unstable based on input values.

---

<div class="post-metadata">

**Author:** ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)\
**Post date:** [August 25, 2018, 7:03am UTC](https://discourse.julialang.org/t/is-a-more-specialized-element-type-of-unique-a-breaking-change/14003/4 "2018-08-25T07:03:12Z")

</div>

> changing return value from `Real` to `Int` , i.e. narrowing down the possible types to return is more specialized \> return

Thx - I’ve clearly missed that type parameters in arrays are invariant while writing the question. I understand that this is not actually a more specialized return type.

It came up as a byproduct of me trying to use `collect()` on an self written Iterator that emits only unique values and the fact that uniqueness is based on `isequal(1,1.) === true`. So the widening on the output doesn’t happen, because the element is never emitted by the iterator. In my mind the results of this algorithm would be _practical covariant_, although I now understand better if people rely on determining type via `unique` their code would fail.

I came across the following behaviour, which, if it would be fixed, would count as breaking too:

```julia
julia> g = (x for x in Float32[1,1.]);

julia> c = collect(g);

julia> typeof(unique(g))
Array{Float32,1}

julia> typeof(unique(c))
Array{Float32,1}

julia> typeof(unique(identity,g))
Array{Any,1} # odd one out

julia> typeof(unique(identity,c))
Array{Float32,1}

```