http://d.puremagic.com/issues/show_bug.cgi?id=8851


monarchdo...@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nob...@puremagic.com        |monarchdo...@gmail.com


--- Comment #4 from monarchdo...@gmail.com 2012-10-19 02:45:07 PDT ---
(In reply to comment #3)
> (In reply to comment #1)
> > I expect that this stems from the stupidity of character literals 
> > defaulting to
> > char rather than dchar, and when you couple that with the fact that 
> > templates
> > always use the _exact_ type of what you give them, it's going to try and
> > instantiate join with a separator of char, which doesn't work with ranges of
> > dchar. I'm not sure how you'd go about fixing that.
> 
> I investigated, and that's not it.
> 
> It's *just* that std.array.join, like std.algorithm.joiner, expects the
> separator to be a range.
> 
> The enhancement request here would be for both "std.array.join"
> std.algorithm.joiner" to accept a single element as a separator.
> 
> In the meantime, of course, a simple workaround is to just "join([sep])".
> 
> I think this needlessly allocates a 1 element array though, no?
> 
> --------
> On a side note, the current restrictions in join are overly restrictive,
> requiring an *exact* ElementType match, making this illegal:
> 
>    int[] sep = [1];
>    double[] z = [[0.1], [0.2]].join(sep);
> 
> The implementation actually perfectly supports it. As a matter of fact, joiner
> supports it. I'll see into relaxing the restraints for now, and taking the
> opportunity to investigate using an element as a separator.

That was fast actually. Both the fix and the enhancement are trivially trivial.
I believe in the change, so I'm assigning to self.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to