virtual structs

[nrc]

No description provided.

[jdm]

Will there be some way for an override method to call the parent type's override implementation?

[jdm]

I would also really like to see casting elaborated upon, with examples, etc.

[nikomatsakis]

I've been thinking more about this. I think that we ought to "close" subtyping so that you can only subtype a virtual struct within the same module (or some submodule).

My reasoning:

1. Prevents people from abusing virtual structs to create an open-ended abstraction: traits are more suitable in such cases.
2. Downcasting is more optimizable, becomes O(1) instead of O(n). This is a common complaint against C++ RTTI (as pointed out on the mailing list).
3. Addresses the private fields initialization gotcha.

Basically, virtual structs become an alternative to enums. To some extent this is the expression problem -- enums are there to provide one half, virtual structs with virtual fns to provide the other half, and traits to solve extensibility.

(There is some sort of precedent, as an aside, with scala's sealed keyword)

[bill-myers]

Closed subtyping seems an extremely interesting idea, because then one could see this not as competition for traits, but rather a generalization of enums.

The current "enum" syntax could be recast as syntax sugar for virtual structs.

This would give "datasort refinements" and "GADTs"/"type parametrization for variants" for free to the enum side, and would give the ability to represent the type tag in ways different than the a vtable pointer (byte-sized tag, null pointer optimization, etc.) to the virtual class side.

I still wonder whether the methods would be better put in named traits, with support for declaring a "vtable trait" on the structs/enums/enums variants.

Maybe there could be some syntax sugar there too, by having a "virtual impl" declarations that would be equivalent to declaring and implementing a trait, and declaring it as a vtable trait, just like the current "impl" behaves like syntax sugar for declaring and implementing a trait.

BTW, I'd suggest then to make the structs either abstract or final, so that it works like the current enum vs enum variant, and doesn't have the issue of having a single identifier that names both a concrete virtual struct, and the set of virtual structs inheriting it.

[nrc]

Incorporated comments from this issue. (Do comments on earlier commits just disappear? I guess I probably shouldn't have force pushed)

[huonw]

If you still have the commit hashes (I guess you do, via git reflog) you can view them at https://github.com/nick29581/rfcs/commit/<commithash> (at least until the commits and/or comments get GC'd by github).

[nikomatsakis]

On Mon, Mar 17, 2014 at 11:32:29PM -0700, Nick Cameron wrote:

Incorporated comments from this issue. (Do comments on earlier commits just disappear? I guess I probably shouldn't have force pushed)

Usually github keeps and lists commented, citing "an outdated version
of this diff". Maybe for RFCs, though, we should avoid force pushing
nonetheless, since rebasing should generally be unnecessary.

[pnkfelix]

(filed as #14)

[adrientetar]

@nikomatsakis The behavior you described only occurs when people comment of the diff tab and not on the commit itself.

[ghost]

Please do not use the word "virtual", nor as a keyword, nor as a name for a feature. Even though i am used primarily to C++, i can not get used to this word. For me it means something that i can see, but is not actually there. Like in "virtual reality" or "virtual memory". The meaning of this word has nothing in common with what you plan to use it for. In source code i think it is the comment which is virtual - it looks to be there, but is actually not real source. Please choose some other words. Perhaps "dynamically dispatchable", ... . You know it better. Just not "virtual" please.

[sinistersnare]

@almale virtual is a well known word in the OO space, and going away from it would cause more confusion to the community,

[nrc]

Closing in favour of other RFCs which address the same problem (see http://discuss.rust-lang.org/t/summary-of-efficient-inheritance-rfcs/494).