Proposal: takeFront and takeBack

Jonathan M Davis jmdavisProg at gmx.com
Wed Jul 4 13:53:48 PDT 2012


On Wednesday, July 04, 2012 21:39:00 Mehrdad wrote:
> IMO the root cause of this problem is something else.
> 
> 
> The problem is that we're trying to use slices as ranges, and
> they don't fit in the model.
> 
> e.g.: If you're using immutable(char)[] to represent a string,
> you're /going/ to run into problems like this (like we already
> have).
> 
> The right thing to do would be to have a separate string type,
> which keeps its front() result, and whatever other information it
> might need. Ditto for other types.
> 
> Yes, this is a breaking change, a pretty significant one.
> 
> But it IS the root cause of the problem.

Well, even if using a struct type which wrapped char[] for string is 
ultimately the better approach (and this situation is one case where it would 
benefit us), I think that it's pretty clear that that ship has long since 
sailed. It would be very hard to convince Walter to change the type of string 
even if D were still in heavy flux, but we've reached the point where breaking 
changes shouldn't happen without great need, and I really don't think that 
anyone is going to convince Walter of that - not without a _very_ strong 
consensus in the D community that the change is worth making (and you're not 
going to get that kind of consensus). So, we have to figure out how to deal 
with the fact that string is immutable(char)[] and make string processing as 
efficient as possible.

Now, another possibility would be to create a wrapper range for strings which 
cached index of the next element when you called front (and maybe cached front 
as well). It couldn't be used in place of strings, because none of the 
functions which special-case strings would know about it, and you'd lose the 
benefits that that provides. But what it _could_ be used for is cases where a 
range-based function knows it's going to wrap a string (e.g. filter or map). 
So, such a function actually wraps a string or wstring in the wrapper range 
when it constructs the range type that it returns. Then you get the benefit for 
functions which can't operate efficiently on a string anymore (even if they 
special case for it), because the string has been wrapped. So, essentially, 
the idea would be to create a more efficient wrapper for strings in cases where 
you're already forced to wrap them.

- Jonathan M Davis


More information about the Digitalmars-d mailing list