On Wed, Feb 24, 2021 at 04:43:57PM +0100, Bengt Gustafsson via Std-Proposals wrote:
> It seems rather common that move constructors and move assignment operators
> need to first move all members and then just set one member in the source to
> indicate that it has been moved from. Couldn't we allow a body after =
> default to handle this situation. Here is today's example:
>
>
> |RasterIO::RasterIO(RasterIO&& src) : m_fileName(std::move(src.m_fileName)),
> m_fileHandle(src.m_fileHandle), m_headerSize(src.m_headerSize),
>     m_footerSize(src.m_footerSize), m_type(src.m_type),
> m_width(src.m_width), m_height(src.m_height), m_depth(src.m_depth),
>     m_frames(src.m_frames), m_fileRowStride(src.m_fileRowStride),
>     m_isRaw(src.m_isRaw), m_description(std::move(src.m_description))
> {
>     src.m_fileHandle = -1;
> }|
>
> |
> |
>
> |Which could be reduced to:|
>
>
> |||RasterIO::|RasterIO(RasterIO&& src) = default {
>     src.m_fileHandle = -1;
> }||
>
> ||The current situation is both boring and reinstates the situation that =
> default was intended to remove, i.e. the verbosity and error proneness.||
>
> ||For constructors it would be possible to also allow : <initializers>
> between default and { which would allow special handling of a subset of the
> members, but I think this would rather rarely be useful.||
>
> ||What do you think?||

Isn't this problem what library fundamentals v3's unique_resource is intended
to solve?

https://cplusplus.github.io/fundamentals-ts/v3.html#scopeguard.uniqueres

/MF