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