std.lifetime?

[Nick Treleaven]

On 12/09/2012 16:09, Nick Treleaven wrote:
> 'make' is basically a generic wrapper for both 'new' expressions and
> struct construction. It also adds makeNew, makeArray and makeStaticArray.
> As std.container is not really the place for construction of
> non-container types, the request moves 'make' to std.conv, because
> 'emplace' is already there, and the two are perhaps related. I don't
> think make or emplace being in std.conv really makes much sense,
> particularly not make.

To explain: make does not convert anything. emplace sometimes converts 
between void[] and T*, but sometimes does no type conversion, depending 
on which overload is used. emplace is more about construction than 
conversion.

If I was wondering which module to import to use makeArray, I would 
first think std.array, then look for a module for more general 
construction (but there isn't one). I wouldn't think to look in 
std.conv. Also note that makeArray is related to 
std.array.uninitializedArray.

> The following existing symbols might benefit from being moved to a
> std.lifetime module, with aliases replacing their existing symbols:
>
> std.container.make
> std.conv.emplace
> std.typecons.scoped
> std.typecons.RefCounted
> std.algorithm.initializeAll

If RefCounted were moved then std.typecons.Unique should probably also be.

But I realize now that moving symbols that aren't in an unexpected place 
(i.e. the std.typecons items) is undesirable and may make Phobos look 
more unstable, even if we don't deprecate the replacement aliases.

On the subject of moving unexpectedly placed symbols, how about moving 
std.exception.assumeUnique to std.conv, as it converts a mutable array 
to an immutable array?

Nick