Rules for allowed return value in combine

[bkamins]

Currently we have:

julia> df = DataFrame(rand(2,2))
2×2 DataFrame
│ Row │ x1      │ x2        │
│     │ Float64 │ Float64   │
├─────┼─────────┼───────────┤
│ 1   │ 0.59547 │ 0.0618626 │
│ 2   │ 0.70438 │ 0.0882641 │

julia> by(df, :x1, z = :x1 => x -> rand(1,1,1))
2×2 DataFrame
│ Row │ x1      │ z          │
│     │ Float64 │ Array…     │
├─────┼─────────┼────────────┤
│ 1   │ 0.59547 │ [0.815674] │
│ 2   │ 0.70438 │ [0.603017] │

julia> by(df, :x1, z = :x1 => x -> rand(1,1))
ERROR: ArgumentError: a single value or vector result is required when passing a vector or tuple of functions (got Array{Float64,2})

This is due to the rule in:
https://github.com/JuliaData/DataFrames.jl/blob/master/src/groupeddataframe/splitapplycombine.jl#L709

I am not 100% this rule is good. I understand the original reason of disallowing them, but it seems that in Pair context it is not ambiguous and we do not need this exception.

@nalimilan - what is your opinion on thins (this is related to select design where I will post a related comment soon)

[nalimilan]

With the objective of releasing 1.0, I'd tend to be as restrictive as possible so that we have time to choose the best behavior later.

But yes it's a bit weird to use arrays as they are, but forbid matrices. I guess for consistency we could treat matrices like higher-rank arrays. Though that means we won't be able to treat them as tables (generating names automatically), which would be another possibility (maybe not that useful).

[bkamins]

Ah - I thought this code path is not invoked in "automatic column name generation" scenario. But you are right and actually it is.

But agreed that we can leave it for later.