www.digitalmars.com         C & C++   DMDScript  

D - C-style array declarations

reply Burton Radons <loth users.sourceforge.net> writes:
Can these please be killed off?  They convolute parsing and dirty up 
declaration syntax, while any use of them has a high likelihood of being 
confused.  The places the standard uses it are at:

http://www.digitalmars.com/d/declaration.html
http://www.digitalmars.com/d/ctod.html (Everywhere within it)
http://www.digitalmars.com/d/arrays.html (Slicing, Array Concatenation, 
Rectangular Arrays)

I'm also very wary of how layers are taken off of types.  On the one 
hand you have:

     int [] *foo; // Pointer to an array of int.
     int [] c = *foo;
     int [] e = foo [0];

On the other hand you have:

     char [int] [] bar; // Associative array using int as key and char 
array as value.
     char [] d = foo [0];

IOW, the unwrapping goes either right-to-left or left-to-right depending 
upon what kind of wrapping type is being taken off - or something like 
that, as the whole thing really makes no sense to me.  I would prefer 
right-to-left consistently, as the latter isn't intuitive:

     alias char [] string;
     string [int] bar; // Identical to the first definition of bar. 
Madness!

This wasn't so important with C; arrays weren't useful.  But in D this 
is really ugly.  Consistency please.
Jan 28 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
I've repeatedly made the call for cast to only be cast(type)var
and like many others think function ptrs should be alias return-type
function ( params ) like delegates
as this solves the problems the parser has (which C does not have) of
knowing if an id is a type or var before the type or var is known.

I also think that arrays and hashtables should be templated items not
buildin as they are
i.e.
hash( value, key ) foo;

but if that is not acceptable I think that
value-type hash ( key-type )  foo; is a lot better
or value-type hash [key-type]

char[] hash( int ) hash ( char[] ) bar;
bar is a hashtable that maps char[] to a hashtable that maps int's to char[]
char[] hash( int hash ( char[] ) ) bar2;
bar 2 is a table table that maps a int to char[] hashtable to char[] etc etc
etc

this makes me think that a new type (a meta class) should exist
delegate, function and hash are all of this new type; unlike other types
meta types must be delclared before use

import meta myfoo; or uses meta myfoo;

so a type is

basic-type ::= basic-type ('*'|('[' <id>? ']') )
type = basic-type meta-class-name [ '(' basic-type [idname] [ ',' basic-type
[idname] ]* ]

(I'm a bit of a fan of getting rid of int[8] too as java has done again
solves some parsing issued with [id] when id is a const and not a type)
int[8] myblock -> int[] myblock = auto int[8]; creates an 8 int array on the
stack
or int[] myblock = static int[8]; (static block); creates an 8 int array in
the bss segment


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b176nu$181m$1 digitaldaemon.com...

 Can these please be killed off?  They convolute parsing and dirty up
 declaration syntax, while any use of them has a high likelihood of being
 confused.  The places the standard uses it are at:

 http://www.digitalmars.com/d/declaration.html
 http://www.digitalmars.com/d/ctod.html (Everywhere within it)
 http://www.digitalmars.com/d/arrays.html (Slicing, Array Concatenation,
 Rectangular Arrays)

 I'm also very wary of how layers are taken off of types.  On the one
 hand you have:

      int [] *foo; // Pointer to an array of int.
      int [] c = *foo;
      int [] e = foo [0];

 On the other hand you have:

      char [int] [] bar; // Associative array using int as key and char
 array as value.
      char [] d = foo [0];

 IOW, the unwrapping goes either right-to-left or left-to-right depending
 upon what kind of wrapping type is being taken off - or something like
 that, as the whole thing really makes no sense to me.  I would prefer
 right-to-left consistently, as the latter isn't intuitive:

      alias char [] string;
      string [int] bar; // Identical to the first definition of bar.
 Madness!

 This wasn't so important with C; arrays weren't useful.  But in D this
 is really ugly.  Consistency please.
Jan 28 2003
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Burton Radons wrote:

 Can these please be killed off?  They convolute parsing and dirty up 
 declaration syntax, while any use of them has a high likelihood of being 
 confused.  The places the standard uses it are at:


You're right that the syntax is terrible because the order of 
significance matters.  I've suggested that we should move the * to the 
left of the base type, and allow parentheses.  As Walter said, it "looks 
weird", but it works:

	// two ways to write an int-indexed array of arrays
	int[int][] bar1;
	(int[int])[] bar2;

	// pointer to array
	*(int[]) baz;

	// array of pointers
	(*int)[] foo;

	// pointer to array of pointers
	*((*int)[]) fred;

D++, maybe.
Jan 31 2003
parent Burton Radons <loth users.sourceforge.net> writes:
Russell Lewis wrote:

 Burton Radons wrote:
 

 Can these please be killed off?  They convolute parsing and dirty up 
 declaration syntax, while any use of them has a high likelihood of 
 being confused.  The places the standard uses it are at:


 
 You're right that the syntax is terrible because the order of 
 significance matters.  I've suggested that we should move the * to the 
 left of the base type, and allow parentheses.  As Walter said, it "looks 
 weird", but it works:


For the quoted paragraph, I was solely meaning support of:

    int x [];

As well as D-style.  D allows both.  But it denies:

    int x [], y;

Because that's defining two types.  Sigh.  It's not even consistent; 
this isn't allowed in DMD:

    int x [], y [];


     // two ways to write an int-indexed array of arrays
     int[int][] bar1;
     (int[int])[] bar2;
 
     // pointer to array
     *(int[]) baz;
 
     // array of pointers
     (*int)[] foo;
 
     // pointer to array of pointers
     *((*int)[]) fred;
 
 D++, maybe.


That doesn't really affect my problem though.  I do not like "char [int] 
[] xyz;" to define an associative array using int for keys and strings 
for values; not on a boat, not on a plane, not having dinner with nice 
champagne; I don't not make no sense of this, I tell you that Mister Lewis.

Usage is another matter.  I don't mind *x being before the value, it's 
like ++x.  Hell, I wouldn't mind getting rid of *x altogether, just use 
x [0].  Makes a mockery of precedence anyway, and it would allow ** to 
mean an exponentiation operator.

Back to arguing against D's syntax.  How about:

     int [4] [5] *x;

Which is both right-to-left and left-to-right.  Then there's function 
pointers that return function pointers.  I can't even make a coherent 
example of that, but using right-to-left with "function" instead of the 
current syntax, a function that takes a float and returns a function 
that takes an int that itself returns void would be:

     void function (int) function (float) moo;

I can't figure out what Russ's syntax would be here, but I think it 
would be the same way as D requires this now with delegates:

     void function (float) function (int) moo;
Jan 31 2003