improving the join function

[Daniel Gibson]

Andrei Alexandrescu schrieb:
> On 10/11/2010 10:34 PM, Daniel Gibson wrote:
>> Andrei Alexandrescu schrieb:
>>> On 10/11/2010 08:57 PM, Daniel Gibson wrote:
>>>> But right now the point is: join() does something completely different
>>>> and should be renamed (or deprecated in std.string and replaced by
>>>> union() - a real join isn't needed in std.string anyway, but when 
>>>> join()
>>>> is deprecated in std.string you can implement a real join in
>>>> std.algorithm without causing too much confusion).
>>>
>>> I think union() is a worse name than join(). The discussion was to
>>> generalize within reason std.string.join, which is present under that
>>> name and with that functionality in many other languages and libraries.
>>>
>>> Andrei
>>
>> Okay, union does kind of suck, because it implies set semantics (and
>> thus no ordering).
>>
>> What about concat()?
>> It seems like join() is expected to work this way for strings.. but as a
>> generic algorithm working on kind-of-cursors?
> 
> I for one would expect join() in its relational sense to work on things 
> quite a bit more structured than just ranges (there's need for indexes 
> etc). Therefore, if relational join() will be introduced later, 
> overloading will disambiguate it. There's no reason to worry.
> 
> Andrei

Of course indexes would speed things up, but as mentioned before join() would work ok on almost(*) 
all ranges (with O(n^2) complexity) and a lot better on std.range.SortedRange.
Because the user would provide a predicate (that should use the same comparator that was used to 
sort the range) no additional structure (metadata like needed for natural join) would be needed.

(*) the inner range needs to be a FordwardRange so it can be traversed multiple times