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
