digitalmars.D - Fixing C-style alias declarations.
- Brian Schott (41/41) Aug 19 2014 No, that's not a typo. "alias" is not meant to be "array" in the
- Brian Schott (3/4) Aug 19 2014 [1]
- ketmar via Digitalmars-d (5/5) Aug 19 2014 On Wed, 20 Aug 2014 00:05:04 +0000
- monarch_dodra (8/16) Sep 04 2014 Good luck with that.
- Gary Willoughby (16/24) Sep 04 2014 I've had problems in the past using the new alias syntax when
- Bruno Medeiros (11/49) Sep 04 2014 They suck don't they? I empathize with you since I also had to write a
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?
Aug 19 2014
"Brian Schott" <briancschott gmail.com> 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
Aug 19 2014
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 '=3D' (ok, let 'alias this' live for now). this will solve all problems.
Aug 19 2014
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.
Sep 04 2014
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.
Sep 04 2014
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
Sep 04 2014