ElementType!string
Jason den Dulk
public2 at jasondendulk.com
Tue Aug 27 04:43:27 PDT 2013
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?
More information about the Digitalmars-d-learn
mailing list