A Modest Proposal: Final class instances

[Jason House]

IMHO, this proposal does not go far enough. THose that worry about performance also care about object size. If a vtable or monitor are needed, then people will still avoid classes for performance.

dsimcha Wrote:

> Several people have griped in the past that D class methods are virtual by
> default.  I've pointed out to them that you can get around this by making the
> methods final.  However, this is a bit of a blunt instrument, because some use
> cases for a single class may call for polymorphism and other use cases for the
> same class may call for fast performance and no polymorphism.  A possible
> solution is, given a class:
> 
> class Foo {
>     // Actual implementation.
> }
> 
> final class FooFinal : Foo{
>     // Dummy that just makes Foo final.
> }
> 
> And then, when you need performance and not polymorphism, you would invoke
> FooFinal instead of Foo.  However, this requires manual forwarding of
> constructors and bloats the name space.  A simple syntactic sugar solution to
> this dilemma that would add very little complexity to the language would be to
> allow final to describe a class instance, as well as a class.  The following
> would apply to a final instance:
> 
> 1.  Method calls don't need to be virtual.
> 2.  An instance of a subclass cannot be converted to a final instance of the
> base class.
> 3.  A final instance can be implicitly converted to a non-final instance, but
> the opposite would not work.
> 
> Using final as an instance attribute like this would also allow another useful
> feature:  Storing class instances inline in arrays, structs, or other classes.
>  Basically, by marking a class instance as final, you'd be telling the
> compiler that you do not need and are not using polymorphism in this case,
> even if the class hierarchy uses it for other use cases, and therefore, all
> relevant optimizations can be made.