std.algorithm.remove and principle of least astonishment

[Bruno Medeiros]

On 16/10/2010 20:51, Andrei Alexandrescu wrote:
> On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:
>> I suggest wrapping a char[] or wchar[] (of all constancies) with a
>> special range that imposes the restrictions.
>
> I did so. It was called byDchar and it would accept a string type. It
> sucked.
>
> char[] and wchar[] are special. They embed their UTF affiliation in
> their type. I don't think we should make a wash of all that by handling
> them as arrays. They are not arrays.
>
>
> Andrei

"They are not arrays."? So why are they arrays then? :3

Sorry, what I mean is: so we agree that char[] and wchar[] are special. 
Unlike *all other arrays*, there are restrictions to what you can assign 
to each element of the array. So conceptually they are not arrays, but 
in the type system they are very much arrays. (or described 
alternatively: implemented with arrays).

Isn't this a clear sign that what currently is char[] and wchar[] (= 
UTF-8 and UTF-16 encoded strings) should not be arrays, but instead a 
struct which would correctly represents the semantics and contracts of 
char[] and wchar[]? Let me clarify what I'm suggesting:
  * char[] and wchar[] would be just arrays of char's and wchar's, 
completely orthogonal with other arrays types, no restrictions on 
assignment, no further contracts.
  * UTF-8 and UTF-16 encoded strings would have their own struct-based 
type, lets called them string and wstring, which would likely use char[] 
and wchar[] as the contents (but these fields would be internal), and 
have whatever methods be appropriate, including opIndex.
  * string literals would be of type string and wstring, not char[] and 
wchar[].
  * for consistency, probably this would be true for UTF-32 as well: we 
would have a dstring, with dchar[] as the contents.

Problem solved. You're welcome. (as John Hodgeman would say)

No?

-- 
Bruno Medeiros - Software Engineer