Final by default? [Decided: No]

[Joseph Rushton Wakeling]

On 13/03/14 16:22, Andrei Alexandrescu wrote:
> On 3/13/14, 2:15 AM, John Colvin wrote:
>> In light of this and as a nod to Manu's expertise and judgment on the
>> matter:
>>
>> We should make his reasoning on the importance of deliberately choosing
>> virtual vs private in API-public classes prominent in documentation,
>> wikis, books and other learning materials.
>>
>> It may not be an important enough to justify a large language break, but
>> if Manu says it is genuinely a problem in his industry, we should do our
>> best to alleviate as much as is reasonable.
>
> I think that's a great idea.

Related suggestion.

I know that Walter really doesn't like compiler warnings, and to a large degree 
I understand his dislike.

However, in this case I think we could do much to alleviate the negative effects 
of virtual-by-default by making it a compiler warning for a class method to be 
without an explicit indicator of whether it's to be final or virtual.

That warning would have to be tolerant of e.g. the whole class itself being 
given a "final" or "virtual" marker, or of tags like "final:" or "virtual:" 
which capture multiple methods.

The warning could include an indication to the user: "If you're not certain 
which is preferable, pick final."

The idea would be that it be a strongly enforced D style condition to be 
absolutely explicit about your intentions final- and virtual-wise.  (If a 
compiler warning is considered too strong, then the task could be given to a 
lint tool.)