Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <7300@brl-smoke.ARPA>
Date: 20 Feb 88 16:15:33 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> <2327@umd5.umd.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <2327@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes:
>>Another thing that should go is the assumption that the unit of storage is
>>the byte.
>I thought about this; it gets sticky, and I am still unsure.  C's
>structure bitfields are the wrong way to get at bits; in particular,
>it would be nice to have arrays of bits.  But the basic unit of
>storage has a way of creeping into the rest of the language, no
>matter how hard one attempts to keep them apart.

It isn't that bad, really -- I once went through an earlier C dpANS
and identified all the changes necessary to support a distinction
between "byte" (smallest accessible storage unit, which could be a
bit if you wanted to make it so) and "character" (smallest unit of
text).  The particular type names I used were "short char" and "char",
respectively.  It turned out that it wasn't too difficult to make
the distinction.  The idea lost out to the "multi-byte character"
approach embodied in the current draft, which is a pity since that
doesn't support bit addressability and it requires specific calls
to convert MBC sequences to and from textual units (wchar_t).  If
you guys really are planning on developing the language D, I hope
you'll consider something along these lines.  By the way, if that
becomes a real project, it should get its own mailing list; there's
too many suggestions for changes to C in this newsgroup already..