[ 2012, Kona ]

Move to NAD.

Unless the library uses the keyword final in a specification, the user clearly has freedom to derive from such a class, and so equally clearly, the library vendor does not have freedom to add a final overrider or class attribute. Howard observed there may be some wiggle-room with 'unspecified types' such as those returned from bind expressions, or iterators, but we did not see a need to further clarify the issue. Note that, for example, a vector::iterator may be implemented as a raw pointer, so users cannot generally assume the ability to derive from unspecified library types.

Related to LWG 2112 the question has been raised whether a library implementation may declare non-polymorphic library components, such as class template std::vector or std::basic_string, as final class types.

This issue is not suggesting to enforce that libraries are required to do that, it is asking whether libraries should have the freedom to do so.

The existing wording in [derivation] does not give a clear permission to do so. In my opinion this position should be clarified in either direction.

Giving implementations this freedom would have both advantages and disadvantages. Several opponents where worried about breakage of code of existing user implementations. On the other hand such types where not designed to be used as base classes. Allowing implementations to mark these components as final could allow them to provide compile-modes that are intentionally restrictive to the advantage of user code that want to be alterted about that. Any implementation that would be concerned about user complaints would not take advantage of this feature anyway.

If agreement exists that such implementation freedom would be useful, wording like

An implementation may declare additional non-virtual member function signatures within a class as final.

or

An implementation may declare additional class without virtual member function signatures as final.

should be added to [conforming] with corresponding exceptions of these rules (e.g. iterator, unary_function, or pair).

If such freedom should not exist, it seems better to clarify this as well, e.g. by adding around [derivation]:

An implementation shall not declare any class or any member function signature as final.