Deprecate C style declerations?

[Hasan Aljudy]

Don Clugston wrote:
> Hasan Aljudy wrote:
>>
>>
>> Gregor Richards wrote:
>>> Jarrett Billingsley wrote:
>>>> "Chris Nicholson-Sauls" <ibisbasenji at gmail.com> wrote in message 
>>>> news:emcekr$2sah$1 at 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

Let's hope Walter hears this before the dead line for v1.0

btw, what do you mean by "C function syntax"?

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

I've always wondered if there's even anyone out there using this so 
called "feature"?
Why would you want to alter the lexer's internal state of the current 
line number?
Who even came up with the idea?

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