You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ok. So the fundamental motivating problem here is broadcasted objects, which have size and getindex methods, but not eltype and setindex! methods. That is, they implement 1/2 of the AbstractArray interface. A lot of methods defined for AbstractArrays, however, do not require eltype nor setindex!. For evidence of this, see #34196. So it would be nice if these methods could be automatically defined for broadcasted objects.
The fundamental problem is that labeling something as AbstractArray is, at least by the interface definition, simply asserting that it has four special methods (getindex, setindex!, eltype, and size). However, this information is contained only in the documentation, and not encoded into the language itself. So solving this problem requires having some way of addressing this information gap.
Therefore, I propose the following:
All abstract types be required to define exactly what fundamental methods are required of them
A way to harness this information during dispatch
I'm not sure of the best way to implement a solution, but I can suggest that solutions should avoid boolean hell. For an extended discussion of the topic of boolean hell, see #35095
Quack quack
The text was updated successfully, but these errors were encountered:
Ok. So the fundamental motivating problem here is broadcasted objects, which have
size
andgetindex
methods, but noteltype
andsetindex!
methods. That is, they implement 1/2 of the AbstractArray interface. A lot of methods defined for AbstractArrays, however, do not requireeltype
norsetindex!
. For evidence of this, see #34196. So it would be nice if these methods could be automatically defined for broadcasted objects.The fundamental problem is that labeling something as AbstractArray is, at least by the interface definition, simply asserting that it has four special methods (
getindex
,setindex!
,eltype
, andsize
). However, this information is contained only in the documentation, and not encoded into the language itself. So solving this problem requires having some way of addressing this information gap.Therefore, I propose the following:
I'm not sure of the best way to implement a solution, but I can suggest that solutions should avoid boolean hell. For an extended discussion of the topic of boolean hell, see #35095
Quack quack
The text was updated successfully, but these errors were encountered: