ElementType!string

[monarch_dodra]

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?

It might, but that range of yours is underwhelming: no indexing, 
no length, no nothing.

Why would you want to do *that* though? Is it because you have an 
ASCII string? In that case, you should be interested in 
std.encoding.AsciiChar and std.encoding.AsciiString.