final
to non-polymorphic components?Section: 16.4.6 [conforming] Status: NAD Submitter: Daniel Krügler Opened: 2011-11-30 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [conforming].
View all issues with NAD status.
Discussion:
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 16.4.6.12 [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 16.4.6 [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 16.4.6.12 [derivation]:
An implementation shall not declare any class or any member function signature as
final
.
[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.
Proposed resolution: