Unexpected behaviour of broadcast getindex.() if there are slices #28031
Description
Toy Example:
(Tested in 0.6 and 0.7-beta.0)
# Nested Array
input = [
[1, 2, 3, 4, 5, 6, 7, 8, 9],
[10, 20, 30, 40, 50, 60, 70, 80, 90],
[100, 200, 300, 400, 500, 600, 700, 800, 900]
]
# For reference, this does what I expect
output = getindex.(input, 3)
# 3-element Array{Int64,1}:
# 3
# 30
# 300
# Unexpected Output
output = getindex.(input, 4:6)
# 3-element Array{Int64,1}:
# 4
# 50
# 600
# What I expected to be returned
output = [getindex(input[1], 4:6), getindex(input[2], 4:6), getindex(input[3], 4:6)]
# 3-element Array{Array{Int64,1},1}:
# [4, 5, 6]
# [40, 50, 60]
# [400, 500, 600]
# This Errors
output = getindex.(input, 4:7)
# ERROR: DimensionMismatch("arrays could not be broadcast to a common size")
# What I expected to be returned
output = [getindex(input[1], 4:7), getindex(input[2], 4:7), getindex(input[3], 4:7)]
# 3-element Array{Array{Int64,1},1}:
# [4, 5, 6, 7]
# [40, 50, 60, 70]
# [400, 500, 600, 700]
Based on the above I assume, that the ranges are not passed verbatim by broadcast to the getindex function. But instead are expanded and participate in the broadcast.
My question now is, is this the desired behaviour and if so is there any non-verbose syntax to achieve what I want assuming I don't know the size of input beforehand and do not want to write a for loop as it interrupts broadcast chaining?
Edit: The current behaviour seems to be that of broadcast_getindex (getting deprecated in favour of the syntax in question in #27075).