make interface types more like closures

[nikomatsakis]

Interface types are really very similar conceptually and in practice to closures. I think we should make them resemble closures more closely both in the language and implementation as follows:

• Make interface instance two words: (vtable, data) (analogous to a closure's (fptr, data))
• Model a vtable with one entry as a single function pointer
• Use type bounds after the iface name to indicate how the data is stored (& vs @ vs ~)

Therefore, for an iface X, the type:

• X indicates any interface instance Such a closure cannot be copied, just as fn cannot be copied
• X&indicates an interface instance whose data is located on the stack.
• X@ indicates an interface instance whose data is boxed
• X~ indicates an interface instance whose data is sendable and stored via unique ptr

Advantages:

• More analogous.
• X~ instances can be sent
• X& instances are particularly cheap to construct
• Closures are a special case of an interface instance (one with a single method), in the impl at least.

[nikomatsakis]

Also, calls are cheaper (one less deref to get vtable)

[marijnh]

The idea with just storing the function pointer for single-method interfaces won't work. The 'dict' stored in the value does not just contain the vtable. If you have for example this impl:

impl <T: to_str> of to_str for [T] { ... }

It must also store the tydesc for T and the dict for the to_str implementation of T that was in scope at the point that created the boxed iface. So you'll always, even for ifaces that themselves do not have parameters, have to allow for these extra fields.

As for the &/~/@ stuff... I'm always grossed out by more sigils being added to say simple things, but I guess this does add expressiveness, and people are already familiar with a similar system for fns, so I could live with it.

[nikomatsakis]

So, the bit about optimizing single-entry vtables is not important, I just threw it in for fun. I'm not surprised it's more complex than I first envisioned. I am more interested in the bounds so that we can make instances sendable and more analogous to closures.

Similarly, I don't have a strong opinion about whether instances should be one or two words, but I think two words would allow us to avoid an allocation in some cases (basically impls over pointer types). I am sure there is a wrinkle there I haven't thought all the way through as well. =)

[marijnh]

It seems people regularly get confused by the iface type name being used both for param bounds and as a boxed iface type. Having a sigil at the end of the boxed type would probably help. I'm liking this proposal more and more.

[nikomatsakis]

I'd be willing to tackle it.

[graydon]

I'm ok with this (though I imagine the trailing sigils will come to have slightly different meaning if and when explicit-region work occurs).

[nikomatsakis]

dup of #3157