Hi,
There's a pull request to enhance std.container.make:

http://dlang.org/phobos/std_container.html#make
https://github.com/D-Programming-Language/phobos/pull/756

'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.

std.typecons was also considered, but make is not a type constructor, it's an instance constructor. Also std.typecons may turn out to be a very big module just from actual type constructors alone.

Thinking about this, I thought perhaps a new module std.construct was warranted. Expanding the scope of construction to lifetime issues, calling it std.lifetime would be more general.

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

Collecting these similar items together should make it easier for newcomers to find them.

Thoughts?

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

On Wed, 12 Sep 2012 17:09:15 +0200, Nick Treleaven <ntrel-public@yahoo.co.uk> wrote:

> 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
>
> Collecting these similar items together should make it easier for newcomers to find them.
>
> Thoughts?

It's no well-kept secret that std.typecons is a jumble of functionality,
and probably the worst in Phobos (which is not very good as a whole).

I am absolutely in favor of gathering this functionality in one,
sensible, place, and think std.lifetime sounds reasonable.

-- 
Simen