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
