Can't use std.algorithm.remove on a char[]?

[ag0aep6g via Digitalmars-d-learn]

On 01.05.2016 07:29, TheGag96 wrote:
> Why exactly is it like this? I would understand why strings (immutable
> character arrays) behave like this, but I feel like plain old character
> arrays should work the same as an array of ubytes when treated as a
> range... Or is there some other string-related behavior that would get
> broken by this?

It's because of auto-decoding. char[] is an array of chars, but it's 
been made a range of dchars. Calling front on a char[] decodes up to 
four chars into one dchar.

Obviously you can't take the address of the dchar, because it's just a 
return value.

You can't assign through front, because the number of chars could be 
different from what's currently there. The whole array would have to be 
re-arranged then, which would be unexpectedly costly for the user.

The auto-decoding behavior was chosen to make dealing with char[] less 
bug-prone. With auto-decoding you don't have to worry about cutting a 
multibyte sequence in half (can still cut a grapheme cluster in half, 
though). However, as you see, it creates other headaches, and it's 
considered a mistake by many. Getting rid of it now would be a major 
breaking change. Could be worthwhile, though.