Immutable separator to join() doesn't work

[Jonathan M Davis]

On 2011-07-11 14:45, Timon Gehr wrote:
> Jonathan M Davis wrote:
> > The solution is to fix template instantiation so that it's smarter when
> > dealing with static arrays and const or immutable arrays:
> > http://d.puremagic.com/issues/show_bug.cgi?id=6148
> 
> Unless I am missing something essential, supporting this would turn the
> complexity of failing template function instantiations to Omega((time for
> matching)*2^(number of const/immutable arrays in the input)). I don't
> think this is too great.
> 
> > It's a language issue, not a design issue. Making ranges function like
> > slists (with head and tail or car and cdr) would be almost certainly be
> > too inefficient (particularly for ranges where save is not super cheap,
> > though it's at least supposed to be fairly cheap).
> 
> That Eg. join cannot take an immutable(char[]) is certainly a design issue.
> I think what you find to be a language issue are limitations inherent to
> templates that are very hard (NP hard in the general case) to overcome.
> 
> > Immutability might be nice, but it
> > does have its costs, and in this case, D's templates aren't currenly
> > smart enough to use immutable(E)[] instead of immutable(E[]).
> 
> I claim they cannot get that smart. If I'm right, this turns it into a
> complete design issue.

I think that they can, but regardless, I don't think that it makes sense to 
redesign ranges at this point. The loss of immutable and const arrays is 
annoying but not all that big a deal. Worst case, casting immutable(E[]) to 
immutable(E)[] solves the problem.

> > And it's not like
> > immutable ranges are going to work with non-array ranges anyway, so it's
> > arguably a good idea to just expect immutable and const ranges to not
> > work anyway.
> > 
> > - Jonathan M Davis
> 
> immutable ranges don't exist in D. immutable arrays do. The issue is that
> many Phobos functions can only take ranges, what excludes immutable
> arrays. That is bad as immutable arrays share many properties with ranges
> and could be used as input to similar algorithms.
> 
> This does not have top priority (at least for me), as it is just a mild
> annoyance that can be worked around. But it needs some thinking.

This enhancement request would make the situation with immutable and const 
arrays so that they're much more in line with mutable container types and 
static arrays:

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

- Jonathan M Davis