www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.lifetime?

reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
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?
Sep 12 2012
next sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
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
Sep 14 2012
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Sep 14 2012