Jonathan M Davis wrote: > On Sunday 10 July 2011 21:09:27 Mehrdad wrote: >> I noticed that the code below doesn't work, and I was wondering if it's >> by design (hopefully not): >> >> immutable SEP = ", "; >> ["a", "b"].join(SEP); >> >> The fact that SEP is immutable(char[]) instead of immutable(char)[] >> shouldn't break the function. > > It most definitely breaks the function, and it's a limitation of templates. > Templates are instantiated with the exact type that they're given, so the > compiler tries to instantiate join with immutable(char[]), but join _can't_ > work with immutable(char[]), because it needs a mutable range. immutable > ranges are worthless. If the compiler were smart enough to realize that it > could instantiate join with immutable(char)[] and it would work, then you > could use immutable(char[]), but since it isn't that smart, it doesn't work. > The same problem happens with static arrays. They can't be used as ranges, so > even though they'd work if the compiler picked a dynamic range as the type for > the function, they don't work, because the compiler isn't that smart. > > The problem may be fixed at some point, but as it stands, it just doesn't work > to use immutable arrays with range-based functions. > > - Jonathan M Davis
There is no such thing as an immutable range because the range abstraction is based on mutation. This does not make sense, because intuitively, immutable(char[]) is a range type just as immutable(char)[] or char[] is a range type. It is quite odd that a data structure can only be a D range if it may be modified... It is not really a compiler issue, but one of library design. Maybe adding a wrapper range to Phobos to iterate over immutable 'ranges' would be an improvement to the current situation. Cheers, -Timon