Should we do this?  As in cause:

# int foo[];
# int bar*;

And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow.  Haven't tried, though.)  Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.

# int num   ,
#     arr[] ,
#     ptr*  ;

vs

# int   num ;
# int[] arr ;
# int*  ptr ;

-- Chris Nicholson-Sauls

"Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:emcekr$2sah$1@digitaldaemon.com...
> Should we do this?  As in cause:
>
> # int foo[];
> # int bar*;
>
> And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow. Haven't tried, though.)

I agree, though

int bar*;

isn't legal any way you slice it, D or C.

I'd also be interested in phasing out the C-style function pointer syntax:

int (*foo)(int, int);
=>
int function(int, int) foo;

> Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.
>
> # int num   ,
> #     arr[] ,
> #     ptr*  ;
>
> vs
>
> # int   num ;
> # int[] arr ;
> # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Jarrett Billingsley wrote:
> "Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:emcekr$2sah$1@digitaldaemon.com...
>> Should we do this?  As in cause:
>>
>> # int foo[];
>> # int bar*;
>>
>> And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow. Haven't tried, though.)
> 
> I agree, though

The syntax of static multidimensional arrays is better using C-style I think:

int[2][3][4] a; //  means a[3][2][1] is max legal index

int a[2][3][4]; //  means a[1][2][3] is max legal index

I hope D gets real multidimensonal arrays eventually though.  Then the need for all those brackets will go away and you'll just have:

   int[2,3,4] a;

In the mean time I've just started www.dsource.org/projects/multiarray to which I will soon upload the ndarray code I've been working on.

--bb

Jarrett Billingsley wrote:
> "Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:emcekr$2sah$1@digitaldaemon.com...
> 
>>Should we do this?  As in cause:
>>
>># int foo[];
>># int bar*;
>>
>>And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow. Haven't tried, though.)
> 
> 
> I agree, though
> 
> int bar*;
> 
> isn't legal any way you slice it, D or C.
> 
> I'd also be interested in phasing out the C-style function pointer syntax:
> 
> int (*foo)(int, int);
> =>
> int function(int, int) foo;
> 
> 
>>Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.
>>
>># int num   ,
>>#     arr[] ,
>>#     ptr*  ;
>>
>>vs
>>
>># int   num ;
>># int[] arr ;
>># int*  ptr ;
> 
> 
> I think that C "feature" was dropped in D because it makes multiple declarations harder to read. 
> 
> 

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X

Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon.

 - Gregor Richards

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:emcjig$30qo$1@digitaldaemon.com...
>
> The syntax of static multidimensional arrays is better using C-style I think:
>
> int[2][3][4] a; //  means a[3][2][1] is max legal index
>
> int a[2][3][4]; //  means a[1][2][3] is max legal index

That's true.  In fact, I think there's a flag in the DMD frontend to make it so that the D-style

int[2][3][4] a;

would have a max index of [1][2][3].  But that goes against the right-to-left rule of declarations..

> I hope D gets real multidimensonal arrays eventually though.  Then the need for all those brackets will go away and you'll just have:
>
>    int[2,3,4] a;

Though they are two different concepts.  If you need a contiguous block of memory which can be accessed with more than one dimension, then a rectangular array is just what you need.  But for most other applications, arrays of arrays are fine, and resizing rectangular arrays is kind of a pain so..

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:emcjig$30qo$1@digitaldaemon.com...
>> The syntax of static multidimensional arrays is better using C-style I think:
>>
>> int[2][3][4] a; //  means a[3][2][1] is max legal index
>>
>> int a[2][3][4]; //  means a[1][2][3] is max legal index
> 
> That's true.  In fact, I think there's a flag in the DMD frontend to make it so that the D-style
> 
> int[2][3][4] a;
> 
> would have a max index of [1][2][3].  But that goes against the right-to-left rule of declarations..

Yeh, that's not a good enough reason to break the nice strict right-to-left consistency D has now.  But I think it may be a good enough reason to leave in the "int a[2][3][4]" syntax.

>> I hope D gets real multidimensonal arrays eventually though.  Then the need for all those brackets will go away and you'll just have:
>>
>>    int[2,3,4] a;
> 
> Though they are two different concepts.  

Yep, different.  I shouldn't have said "all" of them would go away.  I was thinking "many of them".  But maybe even then I was overestimating.

--bb

Gregor Richards wrote:
> Jarrett Billingsley wrote:
>> "Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:emcekr$2sah$1@digitaldaemon.com...
>>
>>> Should we do this?  As in cause:
>>>
>>> # int foo[];
>>> # int bar*;
>>>
>>> And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow. Haven't tried, though.)
>>
>>
>> I agree, though
>>
>> int bar*;
>>
>> isn't legal any way you slice it, D or C.
>>
>> I'd also be interested in phasing out the C-style function pointer syntax:
>>
>> int (*foo)(int, int);
>> =>
>> int function(int, int) foo;
>>
>>
>>> Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.
>>>
>>> # int num   ,
>>> #     arr[] ,
>>> #     ptr*  ;
>>>
>>> vs
>>>
>>> # int   num ;
>>> # int[] arr ;
>>> # int*  ptr ;
>>
>>
>> I think that C "feature" was dropped in D because it makes multiple declarations harder to read.
>>
> 
> Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X
> 
> Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon.
> 
>  - Gregor Richards

Hear hear ..!
I know how you feel!!
I tried to open this subject before, but didn't get anywhere ..

Hasan Aljudy wrote:
> 
> 
> Gregor Richards wrote:
>> Jarrett Billingsley wrote:
>>> "Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:emcekr$2sah$1@digitaldaemon.com...
>>>
>>>> Should we do this?  As in cause:
>>>>
>>>> # int foo[];
>>>> # int bar*;
>>>>
>>>> And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow. Haven't tried, though.)
>>>
>>>
>>> I agree, though
>>>
>>> int bar*;
>>>
>>> isn't legal any way you slice it, D or C.
>>>
>>> I'd also be interested in phasing out the C-style function pointer syntax:
>>>
>>> int (*foo)(int, int);
>>> =>
>>> int function(int, int) foo;
>>>
>>>
>>>> Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.
>>>>
>>>> # int num   ,
>>>> #     arr[] ,
>>>> #     ptr*  ;
>>>>
>>>> vs
>>>>
>>>> # int   num ;
>>>> # int[] arr ;
>>>> # int*  ptr ;
>>>
>>>
>>> I think that C "feature" was dropped in D because it makes multiple declarations harder to read.
>>>
>>
>> Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X
>>
>> Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon.
>>
>>  - Gregor Richards
> 
> Hear hear ..!
> I know how you feel!!
> I tried to open this subject before, but didn't get anywhere ..

I agree, too -- the main reason for retaining it was to simplify conversion from C code to D, but
(a) we now have ctod, so it can be automated in most cases;
(b) in my experience (eg manually translating the Windows headers), it's trivial to translate anyway, and it gives significant benefits to clarity.

The really weird thing about the C syntax is that you can define a *function type* (not just function pointers). There's no D equivalent to that, although I'm not aware of any uses of the construct.

We're building up a list of features that should be deprecated:
* 'length' inside slices.
* C function syntax
* C declaration syntax in general

I'd also add:
* some alternative to #line that doesn't waste the '#' symbol on such a rarely-used feature.

And there are probably a few more I've forgotten about.

Don Clugston wrote:
> I'd also add:
> * some alternative to #line that doesn't waste the '#' symbol on such a rarely-used feature.
I have a alternative suggestion which is syntax in comment for code like:
//LINE: 12
//TODO: add more features
//FIXME: this list is broken

Chris Nicholson-Sauls escribió:
> Should we do this?  As in cause:
> 
> # int foo[];
> # int bar*;
> 
> And others to issue deprecation errors.  I think it would be a good idea, and shouldn't break extern(C) declarations, so long as one doesn't try to mix types.  (I don't think we can mix them in the C way at all, anyhow.  Haven't tried, though.)  Or else change the rules such that array/pointer decoration applies to the variable and not the type -- and correct me if I'm wrong about this not being the current behavior.
> 
> # int num   ,
> #     arr[] ,
> #     ptr*  ;
> 
> vs
> 
> # int   num ;
> # int[] arr ;
> # int*  ptr ;
> 
> -- Chris Nicholson-Sauls

I want this too (to be deprecated)! I want it because of an UI problem. If you have:

# int[] var;

You can tell the type goes from position 0 and has length 5 and the name has position 6 and length 3. However, in

# int var[];

the type and name are mixed. If you want to build an AST that fully represents a source code, including exact positions for each AST node, this is painful. You'd have an AST node for an ArrayType, and another for a Name, but... where does the ArrayType begin and end? Currently in the Descent plugin this information is not guaranteed to be correct in this kind of declarations, but yes in the former ones.

I suggest this syntax to be deprecated. The plugin would allow you to convert a C-style declaration to a D-declaration automatically, it's very easy. I have the information of the AST nodes, and where the delcaration begins and end, so I can do it. In fact, if you write a C-style declaration, in the outline view you can see it in the D-style. :-)