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

make [] give an Any array #8493

Merged
merged 1 commit into from
Sep 29, 2014
Merged

make [] give an Any array #8493

merged 1 commit into from
Sep 29, 2014

Conversation

JeffBezanson
Copy link
Sponsor Member

This change seems to be pretty popular from what I gather.

@jiahao
Copy link
Member

jiahao commented Sep 26, 2014

👍

@ivarne
Copy link
Sponsor Member

ivarne commented Sep 26, 2014

🎆 🍰

@johnmyleswhite
Copy link
Member

+100

@IainNZ
Copy link
Member

IainNZ commented Sep 27, 2014

@StefanKarpinski
Copy link
Sponsor Member

I haven't watched this but I'm assuming you rickrolled us.

On Sep 26, 2014, at 8:23 PM, Iain Dunning [email protected] wrote:

https://www.youtube.com/watch?v=uvqJ1mTkEuY


Reply to this email directly or view it on GitHub.

@JeffBezanson
Copy link
Sponsor Member Author

You know, Array(None,0) is generally pretty bad, but it does have one advantage: it lets you pass [] to any function accepting Array{<:T}, since None is a subtype of everything. It's handy not to need to specify an element type when you want to pass zero elements.

@ivarne
Copy link
Sponsor Member

ivarne commented Sep 27, 2014

@JeffBezanson most of those functions will not work though.

@StefanKarpinski
Copy link
Sponsor Member

Without covariant arrays, that's not all that useful.

@JeffBezanson
Copy link
Sponsor Member Author

Fair enough.

@nalimilan
Copy link
Member

A plotting function with a keyword array argument containing zero or more values, e.g. plot(...; marks::Vector{Int}=[0]), could be called via plot(.., marks=Int[]), but not via f(..., marks=[])? Could be slightly annoying.

But making [] give an Any array has clear advantages in other places.

Or wouldn't it be possible to acknowledge the fact that all empty arrays are alike, so that their element type does not matter? Is there any situation where the element type of an empty array is important?

@JeffBezanson
Copy link
Sponsor Member Author

[] cannot be passed to f(x::Vector{Int}) today, which is why my point above is not very hard-hitting. Only f{T<:something}(x::Vector{T}) would work.

The element type of an empty array absolutely matters, because vectors can grow, and sum(Int[]) will give a different type of zero than sum(Float32[]), etc.

@nalimilan
Copy link
Member

Ah, right. Sometimes you don't care about the type, but sometimes you do. One could imagine converting e.g. Any[] to Int[] when the only signature that matches expects the latter, but that sounds a bit hackish.

@eschnett
Copy link
Contributor

Converting None[] to Int[] would make more sense from a point of view of types, since None is a sub-type of Int...

@StefanKarpinski
Copy link
Sponsor Member

Objects can't change type in Julia and in a dynamic language – especially one with as much polymorphism as Julia – reverse propagation of types is not really feasible.

@IainNZ
Copy link
Member

IainNZ commented Sep 30, 2014

Hard to tell how much this broke as so much still broken from #8420, but, didn't add too many bodies to the dead packages pile.

@JeffBezanson JeffBezanson deleted the jb/emptyany branch October 10, 2014 01:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants