Immutable separator to join() doesn't work

Timon Gehr timon.gehr at gmx.ch
Mon Jul 11 09:06:35 PDT 2011


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




More information about the Digitalmars-d mailing list