Thread overview
Libdparse needs to be updated to recognize AliasAssign declarations
May 04
RazvanN
5 days ago
RazvanN
May 04
user1234
May 04
user1234
6 days ago
user1234
May 04

Hello fellow D people,

Is there anyone in the community sufficiently familiar with libdparse [1] as to make it recognize an AliasAssign declaration [2]? Andralex has made a series of PRs to phobos that make use of the new technology. As a result the code is greatly simplified [3] and it comes with some memory savings [4]. However, these PRs are blocked because of the style checker that does not recognize alias assignments.

If anyone with some experience with the libdparse repo would be able to fix this, that would be greatly appreciated!

Cheers,
RazvanN

[1] https://github.com/dlang-community/libdparse
[2] https://github.com/dlang/dmd/pull/11846
[3] https://github.com/dlang/phobos/pull/8040
[4] https://github.com/dlang/phobos/pull/8033

May 04

On Tuesday, 4 May 2021 at 12:10:55 UTC, RazvanN wrote:

>

Hello fellow D people,

Is there anyone in the community sufficiently familiar with libdparse [1] as to make it recognize an AliasAssign declaration [2]? Andralex has made a series of PRs to phobos that make use of the new technology. As a result the code is greatly simplified [3] and it comes with some memory savings [4]. However, these PRs are blocked because of the style checker that does not recognize alias assignments.

If anyone with some experience with the libdparse repo would be able to fix this, that would be greatly appreciated!

Cheers,
RazvanN

[1] https://github.com/dlang-community/libdparse
[2] https://github.com/dlang/dmd/pull/11846
[3] https://github.com/dlang/phobos/pull/8040
[4] https://github.com/dlang/phobos/pull/8033

This code is fairly clear:

alias A = B;
A = C;

however what about this code?

void foo() {
    alias A = B;
    A = C;
}

is the A = C in this case an AliasAssign? how would the parser differentiate between this AliasAssign and regular assignments?

May 04

On Tuesday, 4 May 2021 at 14:07:47 UTC, WebFreak001 wrote:

>

however what about this code?

void foo() {
    alias A = B;
    A = C;
}

is the A = C in this case an AliasAssign? how would the parser differentiate between this AliasAssign and regular assignments?

AliasAssign is only allowed in declaration contexts--the top level of a module, or the body of a struct, class, template, etc. In these contexts, a normal assignment statement is not allowed, so there is no ambiguity.

Personally I think this is kind of a hack, and would have preferred a separate "rebind" operator to disambiguate (maybe :=). But this is the solution Walter decided on.

May 04

On Tuesday, 4 May 2021 at 14:12:28 UTC, Paul Backus wrote:

>

On Tuesday, 4 May 2021 at 14:07:47 UTC, WebFreak001 wrote:

>

however what about this code?

void foo() {
    alias A = B;
    A = C;
}

is the A = C in this case an AliasAssign? how would the parser differentiate between this AliasAssign and regular assignments?

AliasAssign is only allowed in declaration contexts--the top level of a module, or the body of a struct, class, template, etc. In these contexts, a normal assignment statement is not allowed, so there is no ambiguity.

Personally I think this is kind of a hack, and would have preferred a separate "rebind" operator to disambiguate (maybe :=). But this is the solution Walter decided on.

in that case that will make it easy to add it to libdparse

May 04
On Tuesday, 4 May 2021 at 14:12:28 UTC, Paul Backus wrote:
> On Tuesday, 4 May 2021 at 14:07:47 UTC, WebFreak001 wrote:
>> however what about this code?
>> ```d
>> void foo() {
>>     alias A = B;
>>     A = C;
>> }
>> ```
>>
>> is the `A = C` in this case an AliasAssign? how would the parser differentiate between this AliasAssign and regular assignments?
>
> AliasAssign is only allowed in declaration contexts--the top level of a module, or the body of a `struct`, `class`, `template`, etc. In these contexts, a normal assignment statement is not allowed, so there is no ambiguity.

Am i wrong to think that even without this rule the difference could be made during semantic by testing if the assign lhs is an alias ?

May 04
On Tuesday, 4 May 2021 at 18:48:21 UTC, user1234 wrote:
>
> Am i wrong to think that even without this rule the difference could be made during semantic by testing if the assign lhs is an alias ?

That would break existing code. For example:

    void main() {
        int x = 123;
        int y = 456;
        alias z = x;
        z = y; // runtime assignment
        assert(x == 456);
    }
May 04
On Tuesday, 4 May 2021 at 18:59:05 UTC, Paul Backus wrote:
> On Tuesday, 4 May 2021 at 18:48:21 UTC, user1234 wrote:
>>
>> Am i wrong to think that even without this rule the difference could be made during semantic by testing if the assign lhs is an alias ?
>
> That would break existing code. For example:
>
>     void main() {
>         int x = 123;
>         int y = 456;
>         alias z = x;
>         z = y; // runtime assignment
>         assert(x == 456);
>     }

You can make the difference tho. z is not a type or a compile-time sequence.
May 04
On Tuesday, 4 May 2021 at 19:04:59 UTC, user1234 wrote:
> On Tuesday, 4 May 2021 at 18:59:05 UTC, Paul Backus wrote:
>>
>> That would break existing code. For example:
>>
>>     void main() {
>>         int x = 123;
>>         int y = 456;
>>         alias z = x;
>>         z = y; // runtime assignment
>>         assert(x == 456);
>>     }
>
> You can make the difference tho. z is not a type or a compile-time sequence.

AliasAssign is not limited to just types and compile-time sequences, so I don't see why that's relevant.
6 days ago
On Tuesday, 4 May 2021 at 19:21:36 UTC, Paul Backus wrote:
> On Tuesday, 4 May 2021 at 19:04:59 UTC, user1234 wrote:
>> On Tuesday, 4 May 2021 at 18:59:05 UTC, Paul Backus wrote:
>>>
>>> That would break existing code. For example:
>>>
>>>     void main() {
>>>         int x = 123;
>>>         int y = 456;
>>>         alias z = x;
>>>         z = y; // runtime assignment
>>>         assert(x == 456);
>>>     }
>>
>> You can make the difference tho. z is not a type or a compile-time sequence.
>
> AliasAssign is not limited to just types and compile-time sequences,

Ah yes, this is why I thought it was possible.

> so I don't see why that's relevant.


5 days ago

On Tuesday, 4 May 2021 at 14:18:33 UTC, WebFreak001 wrote:

>

On Tuesday, 4 May 2021 at 14:12:28 UTC, Paul Backus wrote:

>

On Tuesday, 4 May 2021 at 14:07:47 UTC, WebFreak001 wrote:

>

in that case that will make it easy to add it to libdparse

I have made an attempt, if anyone is willing to review: https://github.com/dlang-community/libdparse/pull/441