std.algorithm.remove and principle of least astonishment

spir denis.spir at gmail.com
Sat Nov 20 04:12:04 PST 2010


On Fri, 19 Nov 2010 22:04:51 -0700
Rainer Deyke <rainerd at eldwood.com> wrote:

> On 11/19/2010 16:40, Andrei Alexandrescu wrote:
> > On 11/19/10 12:59 PM, Bruno Medeiros wrote:
> >> 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?
> > 
> > I don't think that would mark an improvement.
> 
> You don't see the advantage of generic types behaving in a generic
> manner?  Do you know how much pain std::vector<bool> caused in C++?
> 
> I asked this before, but I received no answer.  Let me ask it again.
> Imagine a container Vector!T that uses T[] internally.  Then consider
> Vector!char.  What would be its correct element type?  What would be its
> correct behavior during iteration?  What would be its correct response
> when asked to return its length?  Assuming you come up with a coherent
> set of semantics for Vector!char, how would you implement it?  Do you
> see how easy it would be to implement it incorrectly?

Hello Rainer,

The original proposal by Bruno would simplify some project I have in mind (namely, a higher-level universal text type already evoked). The issues you point to intuitively seem relevant to me, but I cannot really understand any. Would be kind enough and expand a bit on each question? (Thinking at people who about nothing of C++ -- yes, they exist ;-)

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com



More information about the Digitalmars-d mailing list