Refine method section

[rossberg]

Broadening the subject and the solution space a little.

[jakobkummerow]

The non-redundant contribution that a built-in method feature (depending, of course, on how exactly it's designed) could make is that it could create a static connection between types and functions/methods (i.e. knowing an object's type, being able to accurately predict a method call's target). That, in turn, could make inlining of methods (which can be waaaaay more impactful that just avoiding a cast) simpler and more reliable. Alternative ideas for accomplishing good inlining do exist, and we'll have to see how much we can get out of them, so it's not clear that we'll need any kind of "built-in vtable" for this. My point is that future experimentation might indicate that this is a stronger reason for adding methods as a primitive than the cast avoidance with its expected 3-4% impact, and the current text doesn't capture that at all.

[tlively]

Expanded scope lgtm.

Could you mention a few of the other known solutions in the text so that we are not dismissing the only listed solution as redundant? Mentioning pros and cons of different solutions would be useful, but I don’t think this much editorializing on the single proffered solution is warranted or helpful.

[rossberg]

I added links to a couple of papers describing approaches of varying complexity and expressiveness and tones down the sentence. (I am hopeful that e.g. the self type from the first paper could probably be integrated into our type syntax in a relatively intuitive fashion, given that we already make recursion explicit.)

[conrad-watt]

I'd not seen that first paper before. If it would be acceptable/possible for us to (soundly) add a special-cased "self quantifier", that does seem to somewhat bridge the gap between the general bounded-quantification-based approach and the totally special-cased object-with-vtable approach.

[tlively]

Thanks, @rossberg! This looks great.