Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abstract element types are not preserved in unique #22696

Closed
ararslan opened this issue Jul 6, 2017 · 1 comment
Closed

Abstract element types are not preserved in unique #22696

ararslan opened this issue Jul 6, 2017 · 1 comment
Assignees
Labels
breaking This change will break code collections Data structures holding multiple items, e.g. sets types and dispatch Types, subtyping and method dispatch
Milestone

Comments

@ararslan
Copy link
Member

ararslan commented Jul 6, 2017

julia> unique(AbstractString["a","b"])
2-element Array{String,1}:
 "a"
 "b"

julia> unique(Integer[1,2])
2-element Array{Int64,1}:
 1
 2

Seems like unique should preserve the element type of the input, regardless of whether it's abstract.

@ararslan ararslan added collections Data structures holding multiple items, e.g. sets types and dispatch Types, subtyping and method dispatch labels Jul 6, 2017
@StefanKarpinski StefanKarpinski added this to the 1.0 milestone Jul 6, 2017
@StefanKarpinski
Copy link
Sponsor Member

Technically breaking, but just mildly so.

@StefanKarpinski StefanKarpinski added the breaking This change will break code label Jul 6, 2017
ararslan added a commit that referenced this issue Aug 10, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
ararslan added a commit that referenced this issue Aug 17, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
ararslan added a commit that referenced this issue Aug 18, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
ararslan added a commit that referenced this issue Aug 21, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
ararslan added a commit that referenced this issue Aug 23, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
ararslan added a commit that referenced this issue Aug 24, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
StefanKarpinski pushed a commit that referenced this issue Aug 24, 2017
Previously the element type of the output was the smallest type that
would fit the union of the input's individual element types. Now the
output has an identical element type to the input. Fixes #22696.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code collections Data structures holding multiple items, e.g. sets types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

No branches or pull requests

2 participants