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.

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.
>

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.

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;