Immutable separator to join() doesn't work

[Timon Gehr]

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.

> 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.

Cheers,
-Timon