Should a variable be visible during its initialization?

Consider the following code:

def var : S8 = someinit;

The question is this: Should the code in someinit be able to see var?

Well, I’m not quite good on it and may be completly wrong.
But, I think it shoud be.

Beeing at the same line where it’s been declarated or in other line, is just circunstantial.

Ins’t it the same code but in two lines?

def var : S8;
S8 = someinit;

The only reason to not allow access to var is for some kind of readability.

Technically, no.

def var1 : S8; // Initialize using default constructor (zero for S8)
def var2 : S8 = 42; // Initialize var2 to 42

With that said, I’m well aware this is a distinction few think about, especially for types (such as the built-in ones) where assignment and construction is, effectively, the same thing.

I have not, yet, made the research I need in order to answer my own question (I know it’s been 2 months. I’ve been rewriting the compiler). As far as I can tell, the main advantage of having the variable visible during construciton is that it’s available as an lvalue. In other words, some function might wish to take its address.

The main advantage of having it not visible is that it does not, yet, obstruct surrounding context’s variables of the same name.

def foo : S8 = 42;
...
if( foo<50 ) {
  def foo : U32 = foo; // This is the outer context's foo
}

Frankly, I find the first unlikely and the second confusing. The question did come up because of the following C++ code:

class C {
  int weight;
public:
  explicit C(int weight) : weight(weight) {}
};

So, at least for method construction, C++ actually does not, yet, have the methods visible during construction.

Yeah.
The C++ construct es very confusing but, at the same time, very intuitive. Maybe because of the special construct syntax. Many times I ended up prepending class variable member by a ‘m’, like ‘mMyVar’ and all is solved :slight_smile: But that is another history.

Anyway, consider allways the compiler evaluation precedence. Do as less exceptions as you can. For sure, you’re doing a left-to-righ evaluation in assignement statements. So, lvalue is defined when rvalue is evaluated. Maybe, for the same reason, in C++ construction member initialization, the class variable member doesn’t hide the local variable: because it’s assigned via (), with higher precedence.