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
