<p dir="auto">Ok. So the fundamental motivating problem here is broadcasted objects, which have <code class="notranslate">size</code> and <code class="notranslate">getindex</code> methods, but not <code class="notranslate">eltype</code> and <code class="notranslate">setindex!</code> methods. That is, they implement 1/2 of the <a href="https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-array-1" rel="nofollow">AbstractArray interface</a>. A lot of methods defined for AbstractArrays, however, do not require <code class="notranslate">eltype</code> nor <code class="notranslate">setindex!</code>. For evidence of this, see <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="542364640" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/34196" data-hovercard-type="pull_request" data-hovercard-url="/JuliaLang/julia/pull/34196/hovercard" href="https://github.com/JuliaLang/julia/pull/34196">#34196</a>. So it would be nice if these methods could be automatically defined for broadcasted objects.</p>
<p dir="auto">The fundamental problem is that labeling something as AbstractArray is, at least by the interface definition, simply asserting that it has four special methods (<code class="notranslate">getindex</code>, <code class="notranslate">setindex!</code>, <code class="notranslate">eltype</code>, and <code class="notranslate">size</code>). 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.</p>
<p dir="auto">Therefore, I propose the following:</p>
<ol dir="auto">
<li>All abstract types be required to define exactly what fundamental methods are required of them</li>
<li>A way to harness this information during dispatch</li>
</ol>
<p dir="auto">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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="580214929" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/35095" data-hovercard-type="issue" data-hovercard-url="/JuliaLang/julia/issues/35095/hovercard" href="https://github.com/JuliaLang/julia/issues/35095">#35095</a></p>
<p dir="auto">Quack quack</p>
<p dir="auto">I think this feature request has not yet its own issue although it has been discussed in e.g. <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="818144" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/5" data-hovercard-type="issue" data-hovercard-url="/JuliaLang/julia/issues/5/hovercard" href="https://github.com/JuliaLang/julia/issues/5">#5</a>.</p>
<p dir="auto">I think it would be great if we could explicitly define interfaces on abstract types. By interface I mean all methods that have to be implemented to fulfill the abstract type requirements. Currently, the interface is only implicitly defined and it can be scattered over several files so that it is very hard to determine what one has to implement when deriving from an abstract type.</p>
<p dir="auto">Interfaces would primary give us two things:</p>
<ul dir="auto">
<li>self documentation of interfaces at a single place</li>
<li>better error messages</li>
</ul>
<p dir="auto">Base.graphics has a macro that actually allows to define interfaces by encoding an error message in the fallback implementation. I think this is already very clever. But maybe giving it the following syntax is even neater:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="abstract MyType has print, size(::MyType,::Int), push!"><pre class="notranslate"><code class="notranslate">abstract MyType has print, size(::MyType,::Int), push!
</code></pre></div>
<p dir="auto">Here it would be neat if one could specify different granularities. The <code class="notranslate">print</code> and <code class="notranslate">push!</code> declarations only say that there have to be any methods with that name (and <code class="notranslate">MyType</code> as first parameter) but they don't specify the types. In contrast the <code class="notranslate">size</code> declaration is completely typed. I think this gives a lot of flexibility and for an untyped interface declaration one could still give quite specific error messages.</p>
<p dir="auto">As I have said in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="818144" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/5" data-hovercard-type="issue" data-hovercard-url="/JuliaLang/julia/issues/5/hovercard" href="https://github.com/JuliaLang/julia/issues/5">#5</a>, such interfaces are basically what is planed in C++ as <code class="notranslate">Concept-light</code> for C++14 or C++17. And having done quite some C++ template programming I am certain that some formalization in this area would also be good for Julia.</p>