Don't we already have String-like support with ranges? I'm not sure I understand the point in having special behavior for char arrays.
Sent from my iPhone On Dec 28, 2011, at 8:17 PM, Andrei Alexandrescu <[email protected]> wrote: > 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 >
