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