Possible Scopebug within if-else blocks?


(SH) #1

Hello :slight_smile:

what I really was wondering, why this code doesnt work:

var y : Int32 := 10;
var p_y : ^Int32 := $0;

if y = 10 then
  var x := 10;
  var y := 20;  //"Duplicate Variable" it prints
  p_y := @y;

p_y^ := 30;

Actually, it should work, because if-else has their own scope within the stack, so it should actually behave like C-if/else codeblocks and I also read the docs for this, in order not to write this, but I couldnt find this anywhere, so is this by design or maybe a sneaky bug ?

Would love to know :slight_smile:


(Carlo Kok) #2

By design and c fails on the same.while they are distinct scopes they are nested. Nested scopes inherit the variables of the scope they are in

(SH) #3

Ah ok, good to know and actually I think this also even better because, consider you have a long calculation going on in the if-block, and do a lot of “complex” stuff with “y” and then you are able to “reuse” y in the parent-scope(out of the if-scope) and you start wondering, why this value didnt change, I think this could happen in a large code base, IMHO

(SH) #4

However, can this code be totally avoidable somehow, because I really cant see any benefit of this :shushing_face::shushing_face:

Proof me wrong, otherwise why it could be useful :wink:

here the code:

if y = 10 then
  var x := 10;
  p_x:= @x;  //bad code!

//this should not compile somehow
var newvar := p_x^;
p_x^ := 200;

(Carlo Kok) #5

That’s quite a hard thing to detect yes. Elements currently does not do any ownership testing.

(SH) #6

Hmm, this is just a really primitive idea, i know, but couldnt the compiler just check if a pointer gets an adress-assignment within a nested scope, like if -block in a function, and immediately he denies compilation when he sees such constructs, where a locasl variable adress is assgined to a pointer, which itself is “globally”, within a function?

In short: If “x” local, means nested in a new scope, (begin/end) then disallow compilation or such ^^?

(Carlo Kok) #7

Yeah. that’s essentially what the borrow check in Rust does. but it becomes a little trickier.


Will this create a thread and do something with x (This needing to extend the lifetime), or will this do something and return?

I’ve got a longstanding issue to look at this, but it’s not as simple as above, if I do it, I want to do it right.

(SH) #8

honestly, I dont understand what you are meaning with this?

Why should this function create a thread?

But to the last, yes of course, just in generell, this shouldnt work, but how and when you solve this is your point :wink:

(Carlo Kok) #9
  var x := 1234;
//  << x is dead here

what if Test stores the parameter value somewhere and does something with it later?

If I do ownership checks, I want to do it right.

(SH) #10

Ah ok, I understand, of course, this shall not work either.

I hope you can fix this somehow :slight_smile:

(SH) #11

Actually, did you logged a bug-request for it?

(Carlo Kok) #12

I did ages ago.