On 2013-12-05 09:09, monarch_dodra wrote:

> Use an output range. It's the generic D approach, and what we already do
> for the string functions such as std.string.translate:
> http://dlang.org/phobos/std_string.html#.translate
> (look down for the output range overloads).
>
> Anything "allocator" related should be carried by the output range
> itself. The function itself should not care nor know about any of that.

In general case, what would you suggest for functions not operating on ranges?

-- 
/Jacob Carlborg

On Thursday, 5 December 2013 at 08:45:08 UTC, Jacob Carlborg wrote:
> On 2013-12-05 09:09, monarch_dodra wrote:
>
>> Use an output range. It's the generic D approach, and what we already do
>> for the string functions such as std.string.translate:
>> http://dlang.org/phobos/std_string.html#.translate
>> (look down for the output range overloads).
>>
>> Anything "allocator" related should be carried by the output range
>> itself. The function itself should not care nor know about any of that.
>
> In general case, what would you suggest for functions not operating on ranges?

How do you mean? As in functions that only output a "single item"?

On 2013-12-05 09:52, monarch_dodra wrote:

> How do you mean? As in functions that only output a "single item"?

Yes.

-- 
/Jacob Carlborg

On Thursday, 5 December 2013 at 08:59:08 UTC, Jacob Carlborg wrote:
> On 2013-12-05 09:52, monarch_dodra wrote:
>
>> How do you mean? As in functions that only output a "single item"?
>
> Yes.

I'd say simply with pass by ref, where the caller for puts the object on the stack (or wherever it wishes). If the object needs to further allocate, the said object itself should know how to it.

In the use case where you *must* have a "foo(ref T* o)"-style signature, I'm not sure.

On 12/5/13 12:52 AM, monarch_dodra wrote:
> On Thursday, 5 December 2013 at 08:45:08 UTC, Jacob Carlborg wrote:
>> On 2013-12-05 09:09, monarch_dodra wrote:
>>
>>> Use an output range. It's the generic D approach, and what we already do
>>> for the string functions such as std.string.translate:
>>> http://dlang.org/phobos/std_string.html#.translate
>>> (look down for the output range overloads).
>>>
>>> Anything "allocator" related should be carried by the output range
>>> itself. The function itself should not care nor know about any of that.
>>
>> In general case, what would you suggest for functions not operating on
>> ranges?
>
> How do you mean? As in functions that only output a "single item"?

Returns a non-linear data structure such as a hash table.

Andrei

On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
> On 12/5/13 12:52 AM, monarch_dodra wrote:
>> On Thursday, 5 December 2013 at 08:45:08 UTC, Jacob Carlborg wrote:
>>> On 2013-12-05 09:09, monarch_dodra wrote:
>>>
>>>> Use an output range. It's the generic D approach, and what we already do
>>>> for the string functions such as std.string.translate:
>>>> http://dlang.org/phobos/std_string.html#.translate
>>>> (look down for the output range overloads).
>>>>
>>>> Anything "allocator" related should be carried by the output range
>>>> itself. The function itself should not care nor know about any of that.
>>>
>>> In general case, what would you suggest for functions not operating on
>>> ranges?
>>
>> How do you mean? As in functions that only output a "single item"?
>
> Returns a non-linear data structure such as a hash table.
>
> Andrei

Output range! :)

Output range interface makes no linearity requirements. Just that: "out.put(this)" compiles.

On 12/5/13 8:19 AM, monarch_dodra wrote:
> On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
>> Andrei
>
> Output range! :)
>
> Output range interface makes no linearity requirements. Just that:
> "out.put(this)" compiles.

Hrm, construction of a hash table is linearizable so bad example on my part. But I'm talking about general structured data such as objects with allocated fields and connections to other objects etc. etc.

Andrei

On Thursday, 5 December 2013 at 16:46:52 UTC, Andrei Alexandrescu wrote:
> On 12/5/13 8:19 AM, monarch_dodra wrote:
>> On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
>>> Andrei
>>
>> Output range! :)
>>
>> Output range interface makes no linearity requirements. Just that:
>> "out.put(this)" compiles.
>
> Hrm, construction of a hash table is linearizable so bad example on my part. But I'm talking about general structured data such as objects with allocated fields and connections to other objects etc. etc.
>
> Andrei

Say, something like a graph? At that point, I'd say you'd have to pass an "allocating scheme" to the function, so an allocator, yes. Depending on the data being generated, the constructed item could carry the allocator itself. For example: auto newNode = myNode.GenerateNeighbor();

In But I think that'd be a special case situation. For everything else, output range is an easy and intuitive, and fits well with the rest of phobos. We'd want (IMHO) to integrate the allocators directly inside the output ranges.

On Thursday, 5 December 2013 at 17:06:13 UTC, monarch_dodra wrote:
> On Thursday, 5 December 2013 at 16:46:52 UTC, Andrei Alexandrescu wrote:
>> On 12/5/13 8:19 AM, monarch_dodra wrote:
>>> On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
>>>> Andrei
>>>
>>> Output range! :)
>>>
>>> Output range interface makes no linearity requirements. Just that:
>>> "out.put(this)" compiles.
>>
>> Hrm, construction of a hash table is linearizable so bad example on my part. But I'm talking about general structured data such as objects with allocated fields and connections to other objects etc. etc.
>>
>> Andrei

> In But I think that'd be a special case situation. For everything else, output range is an easy and intuitive, and fits well with the rest of phobos. We'd want (IMHO) to integrate the allocators directly inside the output ranges.

I really need to re-read myself before posting, sorry :/

But I think that'd be a special case situation. For
everything else, output ranges are easy and intuitive, and
fit well with the rest of phobos. We'd want (IMHO) to
integrate allocation directly inside output ranges.

On Thu, Dec 05, 2013 at 08:46:52AM -0800, Andrei Alexandrescu wrote:
> On 12/5/13 8:19 AM, monarch_dodra wrote:
> >On Thursday, 5 December 2013 at 15:00:07 UTC, Andrei Alexandrescu wrote:
> >>Andrei
> >
> >Output range! :)
> >
> >Output range interface makes no linearity requirements. Just that:
> >"out.put(this)" compiles.
> 
> Hrm, construction of a hash table is linearizable so bad example on my part. But I'm talking about general structured data such as objects with allocated fields and connections to other objects etc. etc.
[...]

I got your point from your previous post. It made me wonder how something like, say, a directed graph could be constructed in a way such that the caller gets to control how memory is allocated. My first thought was to use an abstract factory object that exposes an API that allowed construction of nodes and edges. The function would take this API as argument, and the caller provides the actual implementation.

However, on further thought, this doesn't address the case when the function needs to do something opaque to the API, such as creating a derived class of a graph node (assuming the API has some kind of method that allocates and creates nodes). Ultimately, it seems that an allocator is the only way that doesn't make the caller/callee interface extremely ugly and leaky.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!