On Tuesday, 27 August 2013 at 11:43:29 UTC, Jason den Dulk wrote:
On Sunday, 25 August 2013 at 19:38:52 UTC, Paolo Invernizzi
wrote:
Thanks, somewhat unintuitive.
It is a trap for the unwary, but in this case the benefits
outweigh the costs.
On Sunday, 25 August 2013 at 19:56:34 UTC, Jakob Ovrum wrote:
To get a range of UTF-8 or UTF-16 code units, the code units
have to be represented as something other than `char` and
`wchar`. For example, you can cast your string to
immutable(ubyte)[] to operate on that, then cast it back at a
later point.
To have to use ubyte would seem to defeat the purpose of having
char. If I were to have this:
auto no_convert(C)(C[] s) if (isSomeChar!C)
{
struct No
{
private C[] s;
this(C[] _s) { s = _s; }
@property bool empty() { return s.length == 0; }
@property C front() in{ assert(s.length != 0); } body{
return s[0]; }
void popFront() in{ assert(s.length != 0); } body{ s =
s[1..$]; }
}
return No(s);
}
it's element type would be char for strings. Would this still
result in conversions if I used it with other algorithms?
That should work. It's the functions in std.array that make
ranges out of arrays by provideng empty, front and popFront. As
long as you don't use these, everything is fine.
Actually I think that your wrapper should do the conversion and
std.array should not, but that train is long gone.
