Any reason why `size(x)`, `axes(x, d)`, and `ndims(x)` are not defined for tuples?

[Socob]

julia> versioninfo()
Julia Version 1.8.5
Commit 17cfb8e65ea (2023-01-08 06:45 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 16 × AMD Ryzen 7 4800H with Radeon Graphics
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, znver2)
  Threads: 1 on 16 virtual cores

julia> t = (1, 2, 3)
(1, 2, 3)

julia> size(t, 1)
3

julia> axes(t)
(Base.OneTo(3),)

julia> axes(t, 1)
ERROR: MethodError: no method matching axes(::Tuple{Int64, Int64, Int64}, ::Int64)
Closest candidates are:
  axes(::Tuple) at tuple.jl:28
  axes(::Base.Broadcast.Broadcasted{<:Any, <:Tuple{Vararg{T, N}} where T}, ::Integer) where N at broadcast.jl:227
  axes(::Number, ::Integer) at number.jl:83
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[5]:1

julia> size(t)
ERROR: MethodError: no method matching size(::Tuple{Int64, Int64, Int64})
Closest candidates are:
  size(::Tuple, ::Integer) at tuple.jl:27
  size(::Union{LinearAlgebra.Adjoint{T, var"#s886"}, LinearAlgebra.Transpose{T, var"#s886"}} where {T, var"#s886"<:(AbstractVector)}) at /opt/julia-1.8.5/share/julia/stdlib/v1.8/LinearAlgebra/src/adjtrans.jl:173
  size(::Union{LinearAlgebra.Adjoint{T, var"#s886"}, LinearAlgebra.Transpose{T, var"#s886"}} where {T, var"#s886"<:(AbstractMatrix)}) at /opt/julia-1.8.5/share/julia/stdlib/v1.8/LinearAlgebra/src/adjtrans.jl:174
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[6]:1

julia> ndims(t)
ERROR: MethodError: no method matching ndims(::Tuple{Int64, Int64, Int64})
Closest candidates are:
  ndims(::Base.Iterators.ProductIterator) at iterators.jl:1015
  ndims(::CartesianIndices) at multidimensional.jl:380
  ndims(::AbstractArray{T, N}) where {T, N} at abstractarray.jl:239
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[7]:1

Seems a bit inconsistent and strange given that size(t, d) and axes(t) are implemented, and it’d be trivial to implement. Sample implementation:

size(@nospecialize t::Tuple) = (length(t),)
axes(@nospecialize(t::Tuple), d::Integer) = (d == 1) ? OneTo(length(t)) : throw(ArgumentError("invalid tuple dimension $d"))
ndims(@nospecialize ::Tuple) = 1

I also might have expected there to be fallbacks for size(x, d) and axes(x, d) relying on size(x) and axes(x) (or the other way around).

[jishnub]

The fact that axes works is because of an unfortunate fallback method, but, in general, there's been a consensus against making tuples act more like arrays. If one wants arrays, they may use StaticArrays that wrap Tuples.

[Socob]

I’m not arguing one way or the other whether tuples should act like arrays or not. All I’m saying is that there is a reasonable expectation that, if size(t, d) is defined, that size(t) should be as well, and similarly for axes(t) and axes(t, d). After all, a fallback for all types could be defined via

size(x, d::Integer) = size(x)[d]
axes(x, d::Integer) = axes(x)[d]
ndims(x) = length(axes(x))  # or length(size(x))

It just doesn’t really make sense for one to be defined without the other. So either define all or none of them.

Also, I don’t know what you’re referring to with the “fallback method” for axes. A method for axes(t::Tuple) is explicitly defined here:

julia/base/tuple.jl

Line 30 in c1d1bde

axes(@nospecialize t::Tuple) = (OneTo(length(t)),)

[mkitti]

Triage is too tired to fully evaluate.

• The question should probably be divided since axes seems to have more support.
• Adding the two-argument version of axes has more consensus.
• Jeff says there are reasonable definitions for these, so he is in favor.

History: @mbauman advocated for defining axes for Tuple since it supports broadcasting.

Questions for future triage to consider:

1. Since these operations are implemented by StaticVector are they needed?
2. Should axes(x::Tuple,d) be defined since axes(x) is defined?
3. Should size with one and two arguments be defined?
4. Should ndims(::Tuple) = 1 be defined?

[JeffBezanson]

Yes, might as well define them.

[jariji]

Do we also define these methods for NamedTuple or should these APIs diverge?

[Socob]

@jariji For NamedTuple, none of these are currently defined (including size(nt, d) and axes(nt)), so at least in isolation, there’s currently no inconsistency there. I suppose it could make sense to think about whether there should be symmetry between Tuple and NamedTuple after the final decision on this issue has been made?

[jariji]

I suppose it could make sense to think about whether there should be symmetry between Tuple and NamedTuple after the final decision on this issue has been made?

That seems backwards to me. If there should be a symmetry, then both halves need to be discussed simultaneously before making a decision on either one.

[Socob]

I don’t really see how that’s the case – nothing changes about the existing asymmetry by adding the missing definitions for Tuple, and if the decision is to remove the existing definitions in the future, then symmetry with NamedTuple follows automatically. All I can say is that the NamedTuple situation does not relate to my original issue, but I also don’t have the power to make any decisions here, so I don’t really care either way how this should be discussed.

[mkitti]

To simplify, I would just implement the methods for Tuple in one pull request. NamedTuple could be another pull request.

[nsajko]

This is basically a duplicate of #46480, although the discussion here was more thorough and fruitful.