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.
