December 18, 2008
> Ary Borenszweig:
>> Why, of course, the C syntax for types:
>> int (*x[5])[3];
>> int (*x)(char);
>> int (*[] x)(char);
>> *Ugh*...

bearophile wrote:
> Try porting code that uses heavily n-dimensional tensors from C to D, and you understand why supporting the C syntax for arrays (with inverted coordinates in the definition) is a godsend :-)

Maybe we could enable them conditionally?

pragma(parser, enable_cstyle_func_and_array_decls);
{
    int (*x[5])[3];
}

December 18, 2008
bearophile wrote:
> Ary Borenszweig:
>> Why, of course, the C syntax for types:
>> int (*x[5])[3];
>> int (*x)(char);
>> int (*[] x)(char);
>> *Ugh*...
> 
> Try porting code that uses heavily n-dimensional tensors from C to D, and you understand why supporting the C syntax for arrays (with inverted coordinates in the definition) is a godsend :-)

That's a good point. But can't you do:

extern(C) {
   ...
}

for that? Well, some signatures might leek in the interface, but if they are hard to understand (I could learn them, but if there's a simpler notation, what for?) than it'll be harder to use for D users, and they'll feel they are programming in a mix of C and D, not in D.

> 
> Bye,
> bearophile
December 19, 2008
On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm <kamm-incasoftware@removethis.de> wrote:

>> Ary Borenszweig:
>>> Why, of course, the C syntax for types:
>>> int (*x[5])[3];
>>> int (*x)(char);
>>> int (*[] x)(char);
>>> *Ugh*...
>
> bearophile wrote:
>> Try porting code that uses heavily n-dimensional tensors from C to D, and
>> you understand why supporting the C syntax for arrays (with inverted
>> coordinates in the definition) is a godsend :-)
>
> Maybe we could enable them conditionally?
>
> pragma(parser, enable_cstyle_func_and_array_decls);
> {
>     int (*x[5])[3];
> }
>

They are conditional: you choose to write them or not <g>
December 19, 2008
Reply to cemiller,

> On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm
>
>> pragma(parser, enable_cstyle_func_and_array_decls);
>> {
>> int (*x[5])[3];
>> }
> They are conditional: you choose to write them or not <g>
> 

I want DMD (and grep) to help me chose to not let my minions make me READ them


December 21, 2008
"Christian Kamm" <kamm-incasoftware@removethis.de> wrote in message news:gicsm9$2qiv$1@digitalmars.com...
<snip>
> Maybe we could enable them conditionally?
>
> pragma(parser, enable_cstyle_func_and_array_decls);
> {
>    int (*x[5])[3];
> }

What would this do?  Enable C-style declarations for the whole source file? From this point forward?  Within the active scope?  If it's meant to apply to the content of the given {}, then there should be a semicolon there.

Either way, it wouldn't work.  The whole point of pragmas is for features that a given compiler may or may not support.  And if a given compiler doesn't support this syntax, it will fail regardless.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

December 21, 2008
"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gici0r$2d56$1@digitalmars.com...
> Ary Borenszweig:
>> Why, of course, the C syntax for types:
>> int (*x[5])[3];
>> int (*x)(char);
>> int (*[] x)(char);
>> *Ugh*...
>
> Try porting code that uses heavily n-dimensional tensors from C to
> D, and you understand why supporting the C syntax for arrays (with
> inverted coordinates in the definition) is a godsend :-)

That sounds like a case of wanting to use D for legacy apps.  I'm not sure that we really need C syntax for that, especially considering that legacy apps are one thing in the "Who D is Not For" list.

This syntax ought to be at least deprecated soon, and eventually removed.

Somebody recently exposed an ambiguity in D's syntax due to this legacy: is

   Identifier ( * Identifier ) ( Identifier ) ;

a declaration of a function pointer or a call to a function returned by a function?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

December 21, 2008
Christian Kamm:
>> Maybe we could enable them conditionally?
>>
>> pragma(parser, enable_cstyle_func_and_array_decls);
>> {
>>    int (*x[5])[3];
>> }

Stewart Gordon wrote:
> What would this do?  Enable C-style declarations for the whole source
> file?
> From this point forward?  Within the active scope?  If it's meant to apply
> to the content of the given {}, then there should be a semicolon there.

I assume you mean 'should not be'. That's true, but I didn't want to alter the grammar of the pragma statement to allow for it.

Since there's no dedicated mechanism for compiler control, there aren't many options. I guess a version(CStyle_decls) with the side effect of enabling the parsing of C style declarations inside its block could work too. But it's not pretty either.

> Either way, it wouldn't work.  The whole point of pragmas is for features that a given compiler may or may not support.  And if a given compiler doesn't support this syntax, it will fail regardless.

Well, there are a few predefined pragmas, like msg and lib. This could also be a required, predefined one.

But don't get hung up on the syntax. My main point was that most D modules will not use the C style declarations. They may be useful when porting legacy code though, so being able to enable them on a per file or per block basis seemed like a reasonable compromise if getting rid of them completely is not an option.

December 21, 2008
Christian Kamm wrote:
> Christian Kamm:
>>> Maybe we could enable them conditionally?
>>>
>>> pragma(parser, enable_cstyle_func_and_array_decls);
>>> {
>>>    int (*x[5])[3];
>>> }
> 
> Stewart Gordon wrote:
>> What would this do?  Enable C-style declarations for the whole source
>> file?
>> From this point forward?  Within the active scope?  If it's meant to apply
>> to the content of the given {}, then there should be a semicolon there.
> 
> I assume you mean 'should not be'. That's true, but I didn't want to alter
> the grammar of the pragma statement to allow for it. 

How do you mean, alter the grammar? Pragmas allow
-----
pragma(ident)		   // influence block of declarations
{   declaration;
    declaration;
}
-----
with this type of semantic (see http://www.digitalmars.com/d/1.0/pragma.html).

> Since there's no dedicated mechanism for compiler control, there aren't many
> options. I guess a version(CStyle_decls) with the side effect of enabling
> the parsing of C style declarations inside its block could work too. But
> it's not pretty either.

That's an ugly hack. Don't use a version to do a pragma's job.



Anyway, my vote is for eliminating C-style declarations altogether.
December 21, 2008
Frits van Bommel wrote:
> How do you mean, alter the grammar? Pragmas allow
> -----
> pragma(ident)            // influence block of declarations
> {   declaration;
>      declaration;
> }
> -----
> with this type of semantic (see
> http://www.digitalmars.com/d/1.0/pragma.html).

Ah, I didn't realize that was legal. Thanks for pointing it out!

December 21, 2008
"Christian Kamm" <kamm-incasoftware@removethis.de> wrote in message news:gilm7t$1h2j$1@digitalmars.com...
> Frits van Bommel wrote:
>> How do you mean, alter the grammar? Pragmas allow
<snip>
> Ah, I didn't realize that was legal. Thanks for pointing it out!

Furthermore, you'd have to alter the grammar anyway in order to support this feature, by adding

PragmaStatement:
   pragma ( parser , enable_cstyle_func_and_array_decls ) NoScopeStatementThatMayContainCStyleDecls

among other things.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit.