Yigal Chripun wrote:
Walter Bright Wrote:
Pascal has explicit casts. The integer to character one is CHR(i), the
character to integer is ORD(c).
I meant implicit, sorry about that. The pascal way is definitely the correct
way. what's the semantics in your opinion of ('f' + 3) ? what about ('?' +
4)? making such arithmetic valid is wrong.
Yes, that is exactly the opinion of Pascal. As I said, I've programmed in
Pascal, suffered as it blasted my kingdom, and I don't wish to do that again. I
see no use in pretending '?' does not have a numerical value that is very useful
to manipulate.
I'm sure that the first Pascal
versions had problems which caused you to ditch that language (they where
fixed later).
They weren't compiler bugs I was wrestling with. They were fundamental design
decisions of the language.
I doubt it though that this had a large impact on Pascal's
problems.
I don't agree. Pascal was a useless language as designed. This meant that every
vendor added many incompatible extensions. Anyone who used Pascal got locked
into a particular vendor. That killed it.
The fact that D has 12 integral types is a bad design, why do we need so
many built in types? to me this clearly shows a need to refactor this
aspect of D.
Which would you get rid of? (13, I forgot bool!)
bool byte ubyte short ushort int uint long ulong char wchar dchar enum
you forgot the cent and ucent types and what about 256bit types?
They are reserved, not implemented, so I left them out. In or out, they don't
change the point.
Here's How I'd want it designed: First of, a Boolean type should not belong
to this list at all and shouldn't be treated as a numeric type. Second, there
really only few use-cases that are relevant
signed types for representing numbers: 1) unlimited integral type - int 2)
limited integral type - int!(bits), e.g. int!16, int!8, etc.. 3) user
defined range: e.g. [0, infinity) for positive numbers, etc..
unsigned bit-packs: 4) bits!(size), e.g. bits!8, bits!32, etc..
of course you can define useful aliases, e.g. alias bits!8 Byte; alias
bits!16 Word; .. or you can define the aliases per the architecture, so that
Word above will be defined for the current arch (I don't know what's the
native word size on say ARM and other platforms)
People are going to quickly tire of writing:
bits!8 b;
bits!16 s;
and are going to use aliases:
alias bits!8 ubyte;
alias bits!16 ushort;
Naturally, either everyone invents their own aliases (like they do in C with its
indeterminate int sizes), or they are standardized, in which case we're back to
pretty much exactly the same point we are at now. I don't see where anything was
accomplished.
char and relatives should be for text only per Unicode, (perhaps a better
name is code-point).
There have been many proposals to try and hide the fact that UTF-8 is really a
multibyte encoding, but that makes for some pretty inefficient code in too many
cases.
for other encodings use the above bit packs, e.g. alias
bits!7 Ascii; alias bits!8 ExtendedAscii; etc..
enum should be an enumeration type. You can find an excellent strongly-typed
design in Java 5.0
Those enums are far more heavyweight - they are a syntactic sugar around a class
type complete with methods, interfaces, constructors, etc. They aren't even
compile time constants! If you need those in D, it wouldn't be hard at all to
make a library class template that does the same thing.
