Andrei Alexandrescu Wrote: > On 11/22/10 5:59 PM, foobar wrote: > > Canonical example: DNA. > > I shouldn't need to write a special function to print it since it IS a > > string. > > I shouldn't need to cast it in order to do operations on it like sort, > > find, etc. > > I think it's best to encode DNA strings as sequences of ubyte. UTF > routines will work slower on them than functions for ubyte. >
how would I go about printing DNA sequences then? printing a ubyte should print it's numeric value, and NOT a char. What actually needed here is a ASCIIChar type or even a more stricter DNAChar. > > D's [w|D|]char types make no sense since they are NOT characters and the > > concept doesn't fit for unicode since as someone else wrote, there are > > different levels of abstractions in unicode (copde point, code unit, > > grapheme). > > Naming matters and having a cat called dog (char is actually code unit) is > > a source of bugs. > > I think the names are fine. It doesn't take much learning to understand > that char, wchar, and dchar are UTF-8, UTF-16, and UTF-32 code units > respectively. I mean it would be odd if they were something else. > > The isn't a quantitative issue but an existential one. I agree that it's easy to use dogs once someone tells you that everywhere you want a dog you should denote it with "cat". Why do you need to learn that mistake _AT_ALL_ ? it is odd for YOU to think otherwise because you have ALREADY learned and accustomed to use a "cat" every time you need a dog. That does not mean that this is indeed correct. This is the same issue people having with D's enum. You just don't seem to get that learning is location depended. What makes sense to YOU based on your location on the learning curve isn't absolute and does NOT reflect on people with a different location on the learning curve. This goes with many of your excellent implementations that get awful names. Very C++ on your part - you need to be a c++ guru just to write a hello world app. > Andrei
