string is rarely useful as a function argument

[Andrei Alexandrescu]

On 12/28/11 4:18 PM, foobar wrote:
> On Wednesday, 28 December 2011 at 21:57:00 UTC, Andrei Alexandrescu wrote:
>> On 12/28/11 1:48 PM, foobar wrote:
>>> On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei Alexandrescu
>>> wrote:
>>>> On 12/28/11 1:18 PM, foobar wrote:
>>>>> That's a good idea which I wonder about its implementation strategy.
>>>>
>>>> Implementation would entail a change in the compiler.
>>>>
>>>> Andrei
>>>
>>> Why? D should be plenty powerful to implement this without modifying the
>>> compiler. Sounds like you suggest that char[] will behave differently
>>> than other T[] which is a very poor idea IMO.
>>
>> It's an awesome idea, but for an academic debate at best.
>>
>> Andrei
>
> I don't follow you. You've suggested a change that I agree with. Adam
> provided a prototype string library type that accomplishes your
> specified goals without any changes to the compiler. What are we missing
> here? IF it boils down to changing the compiler or leaving the
> status-quo, I'm voting against the compiler change.

If we have two facilities (string and e.g. String) we've lost. We'd need 
to slowly change the built-in string type.

I discussed the matter with Walter. He completely disagrees, and sees 
the idea as a sheer way to complicate stuff for no good. He mentions how 
he frequently uses .length, indexing, and slicing in narrow strings.

I know Walter's code, so I know where he's coming from. He understands 
UTF in and out, and I have zero doubt he actually knows all essential 
constants, masks, and ranges by heart. I've seen his code and indeed 
it's an amazing feat of minimal opportunistic on-demand decoding. So I 
know where he's coming from, but I also know next to nobody codes like 
him. A casual string user almost always writes string code (iteration, 
indexing) the wrong way and would be tremendously helped by a clean 
distinction between abstraction and representation.

Nagonna happen.


Andrei