No, that's not a typo. "alias" is not meant to be "array" in the subject line.

Consider the following code:
---
alias A = int[]; // Ai
alias int B[]; // Ai
alias C = int function(int); // PFiZi
int D(int); // FiZi
alias int E(int); // FiZi
alias int F[], G[]; // test.d(6): Error: multiple declarations
                    // must have the same type, not int[] and int[]
---

Most of you are probably confused that line 2 compiles. Well, it does. D's
broken support for C-style array declarations is back. Just for fun, check line
6. It doesn't compile.

On line 5 you find the kind of code that made me aware of this in the first
place. The problem here is that if you apply the same logic that transforms line
2's alias declaration into line 1, you end up with line 3, which has the wrong
"deco" according to the compiler's output, or "alias C = int(int);", which does
not compile. From this I come to line 4, which is really obvious, and appears to
be the same as the declaration on line 5. This raises the question of why the
"alias" keyword is on this[1] line of core.sys.windows.threadaux. This is even
more puzzling when you consider the fact that the only time this alias is used
is as "fnNtQuerySystemInformation*". That is, if the syntax on line 3 of the
example code was used, fnNtQuerySystemInformation would already be a pointer
and the "*" could be dropped from its usage. Can anybody come up with a use case
for aliasing a function type but not its pointer type?

On Wednesday, 20 August 2014 at 00:05:04 UTC, Brian Schott wrote:
> this[1] line of

[1] https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/threadaux.d#L110

On Wed, 20 Aug 2014 00:05:04 +0000
Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

i think that it's time to kill both c-like array declarations and old-style aliases w/o '=' (ok, let 'alias this' live for now). this will solve all problems.

On 20/08/2014 01:05, Brian Schott wrote:
> No, that's not a typo. "alias" is not meant to be "array" in the subject
> line.
>
> Consider the following code:
> ---
> alias A = int[]; // Ai
> alias int B[]; // Ai
> alias C = int function(int); // PFiZi
> int D(int); // FiZi
> alias int E(int); // FiZi
> alias int F[], G[]; // test.d(6): Error: multiple declarations
>                      // must have the same type, not int[] and int[]
> ---
>
> Most of you are probably confused that line 2 compiles. Well, it does. D's
> broken support for C-style array declarations is back. Just for fun,
> check line
> 6. It doesn't compile.
>
> On line 5 you find the kind of code that made me aware of this in the first
> place. The problem here is that if you apply the same logic that
> transforms line
> 2's alias declaration into line 1, you end up with line 3, which has the
> wrong
> "deco" according to the compiler's output, or "alias C = int(int);",
> which does
> not compile. From this I come to line 4, which is really obvious, and
> appears to
> be the same as the declaration on line 5. This raises the question of
> why the
> "alias" keyword is on this[1] line of core.sys.windows.threadaux. This
> is even
> more puzzling when you consider the fact that the only time this alias
> is used
> is as "fnNtQuerySystemInformation*". That is, if the syntax on line 3 of
> the
> example code was used, fnNtQuerySystemInformation would already be a
> pointer
> and the "*" could be dropped from its usage. Can anybody come up with a
> use case
> for aliasing a function type but not its pointer type?

They suck don't they?  I empathize with you since I also had to write a D parser, and thus had to write parsing for that syntax (I assume that's why you dislike it as well).

At first I didn't even notice this syntax existed (I don't think it was mentioned in the docs when I was writing the parser), it was only when I put the whole source of Phobos in the unit-tests that I noticed it was there... :S

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Wednesday, 20 August 2014 at 00:17:06 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 20 Aug 2014 00:05:04 +0000
> Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> i think that it's time to kill both c-like array declarations and
> old-style aliases w/o '=' (ok, let 'alias this' live for now). this
> will solve all problems.

Good luck with that.

C-style will remain if only to make it easy to port C code.

Old style alias stays, because new style is what, 1 year old? Are you seriously suggesting we break *any* D code that is older than that? I'm sure Walter and Andrei will be REAL receptive to your suggestions.

On Wednesday, 20 August 2014 at 00:17:06 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 20 Aug 2014 00:05:04 +0000
> Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> i think that it's time to kill both c-like array declarations and
> old-style aliases w/o '=' (ok, let 'alias this' live for now). this
> will solve all problems.

I've had problems in the past using the new alias syntax when porting C headers.

Stuff like this:

alias extern(C) uint function(Tcl_HashTable* tablePtr, void* keyPtr) nothrow Tcl_HashKeyProc;
alias extern(C) int function(void* keyPtr, Tcl_HashEntry* hPtr) nothrow Tcl_CompareHashKeysProc;
alias extern(C) Tcl_HashEntry* function(Tcl_HashTable* tablePtr, void* keyPtr) nothrow Tcl_AllocHashEntryProc;
alias extern(C) void function(Tcl_HashEntry* hPtr) nothrow Tcl_FreeHashEntryProc;

Stuff like this used to fail in the new style.

Incidentally, i've just ported this to the new style and it now compiles. I suggest keeping the old style for a while longer.