On Mon, 11 Oct 2010 23:34:41 -0400, Daniel Gibson <metalcae...@gmail.com>
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?
std.algorithm already has some operations that are also in the
relational algebra (setDifference, setIntersection, setUnion, Filter,
even Group (like in group by) etc), adding a join (as in relational
algebra join) implementation would only make sense - but how are you
gonna name that thing if join() is already taken for some kind of
"concatenation with additional seperator"?
Sure, "setJoin" would be available, but having both join and setJoin
doing completely different things would be confusing.
What about something like
char[] concat(char[][] words, char[] sep="") // or sep=null
in the string case and something equivalent in the ranges case?
Cheers,
- Daniel
Regarding the bike shed,
Well, std.range already has transversal( range_of_ranges , Nth) and
frontTransversal(range_of_ranges). So there is some opportunity for both a
transverse all elements, i.e. transversal( range_of_ranges ), and
interleaved elements, i.e. transversal( range_of_ranges, separator ).
