fieldnames broken for tuples

[SimonDanisch]

t = Tuple{Float32,Float32}
nfields(t) == 2, although tuples don't have fields.
So fieldnames(t) results in a BoundsError.

[SimonDanisch]

julia> versioninfo()
Julia Version 0.5.0-dev+2406
Commit 03f0259 (2016-01-29 21:29 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1

[vtjnash]

it has fields, although those fields don't have names. but we can look at the other properties of those fields:

julia> t.types
svec(Float32,Float32)

julia> x=(1.2, 3.2, 4.5)
(1.2,3.2,4.5)

julia> x.(3)
4.5

[yuyichao]

Maybe we can return an symbol("") as the field name instead of raising an error like what we do for the anonymous fields in LambdaStaticData?

[eschnett]

fieldnames used to return an empty array for tuples in Julia 0.4. It could do the same here in Julia 0.5.

[SimonDanisch]

I think this should definitely not error: [x.(name) for name in fieldnames(x)]...
So fieldnames for tuples must return either [1,2,3...], or Symbol[], since [symbol(""), symbol(""), ...] would give a weird result.

[eschnett]

For the record, here is the error message:

julia> fieldnames(Tuple{Int})
ERROR: BoundsError: attempt to access svec()
  at index [1]
 in getindex at /Users/eschnett/julia05/lib/julia/sys.dylib
 in fieldnames at /Users/eschnett/julia05/lib/julia/sys.dylib
 in eval at /Users/eschnett/julia05/lib/julia/sys.dylib

[yuyichao]

I think this should definitely not error: [x.(name) for name in fieldnames(x)]...

What is it used for? Does [x.(i) for i in 1:nfields(x)] works?

[SimonDanisch]

Yes, but what is getfield(x, symbol("")) supposed to do?
I simply think they should be symmetric. The api is pretty much like: here is a method to get all fieldnames, and here is a way to access a field with a name...
But you're right, it's definitely not necessary. It's just the question what we tell people, when explaining them what a field in julia is... If fieldnames returns an array of empty symbols, then you might argue that this should be possible:

immutable X
::Int
::Int
end

[JeffBezanson]

Empty symbols are wrong here. The 3 viable options are

1. Give "error: type has no field names"
2. Return an empty array
3. Return an array of integers 1:n

[JeffreySarnoff]

@JeffBezanson Of the three, I suggest "3. Return an array of integers 1:n"

It meshes best:

type Fields
   field1::Int
   field2::Int
end
fields = Fields(10,20)

atuple = (10,20)

nfields(fields) == nfields(atuple) == 2

getfield(fields, fieldnames(fields)[2])
20

and if fieldnames(atuple) evaluates as [1,2] or evaluates as (1,2)

getfield(atuple, fieldnames(atuple)[2])
20

[SimonDanisch]

I'll vote for 2, it's how it was done before and makes tuple act more like an array. And we don't have to widen the semantics of fieldnames... In general, I find it reasonable to hide away the fact, that a tuple has fields as much as most other composite types...

[StefanKarpinski]

Returning integers seems consistent with the premise that a tuple is like struct without field names.