www.digitalmars.com         C & C++   DMDScript  

D - language definition unfit for 64bit platforms

reply Andreas Kaiser <A.Kaiser gmx.net> writes:
	Problem: 

In the current language definition, the data type of an
non-associative array index is fixed to int and uint, mostly implied
by context and not explicitly mentioned. But "foreach" is explicitly
defined this way. The portability guide recommends using size_t, but
I'm certain we'll see an ugly mix of ints, longs and size_t in
declarations and use all over the place.

While a 64bit implementation could bend the language definition by
unconditionally substituting long/ulong for the index type breaking
"foreach" compatibility, I recommend a different approach which also
allows for important type checks in those critical areas.

I'd guess we'll need a few compiler warnings come up at that time,
like it or not... but it's really nice to see some diagnostics if an
int is used for an array having its index specifically declared to be
a long thereby signalling that an int is not sufficient.
Unconditionally having all arrays indexed by long does not allow for
such diagnostics.

	Proposal: 

(a) The index data type should be part of the array declaration,
defaulting to int. Example:
	double[int] a; // same as double[] a;
	byte[long] b;
This is consistent with the syntax used for associative arrays. Any
integral data type should be allowed, because together with enums like
	enum Tag ( A,B,C };
	char[][Tag] tag2text;
we also get an additional level of compile time check as an accidental
use of plain integers yields errors.

(b) To ease generic code, there should be a way to use foreach without
having secret knowledge of both the array element type and the index
data type. Something like
	foreach (indextypeof(a) i, elementtypeof(a) x; a) { ... }
instead of
	foreach (int i, double x; a) { ... }
	foreach (char[] i, byte x; b) { ... }
depending on what kind of array it is. For the index type some new
language item might be necessary. For the element data type I'm
uncertain as typeof(*a) seems to work at the moment whereas
typeof(a[]) does not, but this is probably not intentional and
certainly not nice.



Gruss, Andreas
Jun 01 2004
parent Daniel Horn <hellcatv hotmail.com> writes:
I agree arrays should be allowed to be larger on 64 bit platforms
but it's also nice to have 32 bit arrays that you know won't be 64 
bit... your solution seems to address these concerns.
however I'd like to inform you that the newsgroup to which you posted is 
obsolete. I'm replying to both D and digitalmars.D so your post gets 
some face-time.
-Daniel
Andreas Kaiser wrote:


 	Problem: 
 
 In the current language definition, the data type of an
 non-associative array index is fixed to int and uint, mostly implied
 by context and not explicitly mentioned. But "foreach" is explicitly
 defined this way. The portability guide recommends using size_t, but
 I'm certain we'll see an ugly mix of ints, longs and size_t in
 declarations and use all over the place.
 
 While a 64bit implementation could bend the language definition by
 unconditionally substituting long/ulong for the index type breaking
 "foreach" compatibility, I recommend a different approach which also
 allows for important type checks in those critical areas.
 
 I'd guess we'll need a few compiler warnings come up at that time,
 like it or not... but it's really nice to see some diagnostics if an
 int is used for an array having its index specifically declared to be
 a long thereby signalling that an int is not sufficient.
 Unconditionally having all arrays indexed by long does not allow for
 such diagnostics.
 
 	Proposal: 
 
 (a) The index data type should be part of the array declaration,
 defaulting to int. Example:
 	double[int] a; // same as double[] a;
 	byte[long] b;
 This is consistent with the syntax used for associative arrays. Any
 integral data type should be allowed, because together with enums like
 	enum Tag ( A,B,C };
 	char[][Tag] tag2text;
 we also get an additional level of compile time check as an accidental
 use of plain integers yields errors.
 
 (b) To ease generic code, there should be a way to use foreach without
 having secret knowledge of both the array element type and the index
 data type. Something like
 	foreach (indextypeof(a) i, elementtypeof(a) x; a) { ... }
 instead of
 	foreach (int i, double x; a) { ... }
 	foreach (char[] i, byte x; b) { ... }
 depending on what kind of array it is. For the index type some new
 language item might be necessary. For the element data type I'm
 uncertain as typeof(*a) seems to work at the moment whereas
 typeof(a[]) does not, but this is probably not intentional and
 certainly not nice.
 
 
 
 Gruss, Andreas
Jun 01 2004