Functions taking collections of column names always require them to be in AbstractVectors

[oxinabox]

For example: disallow_missing,

DataFrames.jl/src/dataframe/dataframe.jl

Line 991 in 8d6cd43

function disallowmissing!(df::DataFrame, cols::AbstractVector{<: ColumnIndex}=1:size(df, 2))

I wanted to use a tuple of column names,
because tuples are immutable, and have much better performance,
and I knew all the columns when i wrote the code.

cc: @glennmoy

[bkamins]

We have recently switched DataFrame constructor to accept tuples in some cases. I guess we could widen this approach to other functions. Let us keep this open to be decided before 1.0 release.

The only question is whether it should be AbstractVector or Tuple or a general iterator and we dynamically check what eltype it has (in DataFrame constructor we strictly require AbstractVector or a Tuple).

[oxinabox]

I think it is fine to do a general iterator, and implictly check the type.
It is not like we would ever want to dispatch on this, would we?

[bkamins]

@nalimilan - we need a general decision here (I am OK with accepting a general iterator and doing a type check, which will be tricky but doable). The downside is that the code will not be type stable (but I think it will not be the end of the world as DataFrames.jl are not type stable anyway).

[nalimilan]

I agree we should support any iterator where possible (even if there won't probably be any performance gain). In the present case we could probably just remove the type annotation and rely on the fact that the one for ::ColumnIndex is more specific and will therefore be called when passed a symbol or integer, right?

[bkamins]

The trick is that normally we require homogeneous type in other methods (or in short: that symbols and numbers are not mixed). That is why I have said that we have do do a type check anyway.

I think we should retain this guarantee. I do not see much sense to allow selection of [1, :some_col, 2, :some_other_col. Agreed?

[bkamins]

Although we currently allow it for AbstractVector with the signature we have now (but we could clean it up if we make the change how the method works).

[nalimilan]

Yeah, but it sounds weird to make the code much more complex just to prevent that. With some functions things can go wrong if duplicates are passed, but that's not the case here.

[bkamins]

OK (in normal code it will probably not happen anyway).

[bkamins]

As discussed in #2156 we can start allowing passing tuple instead of a vector. Just note that you should not expect a huge performance gain here (anything that happens with the selector will allocate much more and take much more time) - so this would be just a convenience functionality to allow tuples. Is the request then still valid, or vectors are enough?

[oxinabox]

I guess there is always static vectors.
Since this is non-breaking its not worth thinking about this til after 1.0

[bkamins]

This is now supported with Cols, e.g. Cols(:a, :b, :c).