View Issue Details

IDProjectCategoryView StatusLast Update
0000861LDMudLPC Compiler/Preprocessorpublic2019-11-24 14:45
ReporterGnomi Assigned ToGnomi  
Status resolvedResolutionfixed 
Summary0000861: Variable initializer uses to-be-initialized variable
DescriptionGiven the following file:

int x = 42;

int fun() { int x = x - 1; return x; }

The function will return -1.

Another case is where you want to catch variables by reference for a closure:

closure fun()
    int a = 1;
    return function int() : int a = &a { return a; }

Here funcall(fun()) will return 0 instead of 1.

The reason is, that the expression at the right hand side of the assignment will already use the declaration left of the assignment operator. I think this behavior is not intuitive and should be changed.
TagsNo tags attached.
External Data (URL)



2018-02-07 20:39

manager   ~0002454

C has the same behavior (initializer uses the initialized variable). But most of the time it will result in undefined behavior. It's there, so you can take the address of the to-be-initialized variable and use that in the initializer.

In LPC it would be the same with the reference operator, but I see even fewer use cases here than in C.


2018-02-08 00:37

administrator   ~0002455

I agree... I would prefer to use the existing variable until the initialization is complete...
I assume, in case there is no existing variable in an outer scope, such an initializer will then cause an error? The other way, that it falls back to the to-be-initialized var would be not consistent I think.


2018-02-26 21:26

administrator   ~0002457

BTW: One of our wizards commented, he would expect that there would be warning that the inner/new variable shadows the outer one.


2018-02-26 21:50

manager   ~0002458

The warning comes only if a local variable shadows another local variable. In the examples above (local variable shadowing a global variable, closure context variable shadowing outer local variable) the compiler currently doesn't give any warnings.


2019-11-24 14:45

manager   ~0002494

Fixed in current master.

Issue History

Date Modified Username Field Change
2018-02-04 01:04 Gnomi New Issue
2018-02-04 01:04 Gnomi Status new => assigned
2018-02-04 01:04 Gnomi Assigned To => Gnomi
2018-02-07 20:39 Gnomi Note Added: 0002454
2018-02-08 00:37 zesstra Note Added: 0002455
2018-02-26 21:26 zesstra Note Added: 0002457
2018-02-26 21:50 Gnomi Note Added: 0002458
2019-11-24 14:45 Gnomi Status assigned => resolved
2019-11-24 14:45 Gnomi Resolution open => fixed
2019-11-24 14:45 Gnomi Note Added: 0002494