In my opinion it seems logical that an ivar assignment behaves the same whether it is inside an initialize method or at class scope. I always figured these initializers as being in some kind of virtual initialize which is always called before the actual method. This can be particularly useful to make sure an ivar is always initialized even with subclass overrides of initialize. I'm not aware of a specific use case regarding instance methods, though.
I suppose the same sanity-checks could be applied to ivar initializers as inside an initialize method.

On the other hand, it's probably not that important and having a consistent rule is fine either way.

I just don't see an issue with CONST = bar and @ivar : Int32 = bar referring to different bar methods. The identifiers CONST and @ivar themselves are on different scopes, so it makes perfect sense that their value expression can be differently scoped as well.

Yeah, maybe it should run at the instance level. I'm not sure yet, so for now let's not merge this.

ivar assignments are done at the class level so why should they be resolved differently? (see Ruby)

@Sija @straight-shoota What do you mean? There's no such thing in Ruby. When you do @x = 1 at the class level in Ruby, it assigns an instance variable of the class, not of the instance. In Crystal we want a different behavior for that same line.

@Sija Even if Ruby was different... In Crystal @x : Int32 declares a varibale in instance scope, so it would by no means be a surprise to anyone if the second part = bar also resolves in instance scope (it doesn't necessarily need be that way, type scope should be ok, too).

@asterite @straight-shoota Sorry, my bad! I already forgot that in Ruby @ivars can be declared only inside of instance methods... Too much Crystal lately 😅 Still, with the issue at hand @x = bar declaration is happening inside of the class scope, so IMHO it intuitively should refer to to class rather than instance (you can always use it like that inside of initialize).

And you can always reach class scope with self.class 😛

Actually, I tried to see if I can fix a few issues regarding initializers and instance vars... but it's all a big mess, in addition to how generics work or are implemented. I don't feel like fixing this by adding more patches and hacks. As usual, I believe it's better to have a good portion of time to rewrite the compiler from scratch, in a readable, efficient, well thought-out way (though at least I won't do that, ever, but if Crystal ever gets enough money to do it, I'd advise to do it).

@asterite I'm sure rewriting or refactoring portions of the compiler will be far more productive then throwing out the entire thing. If you're working on fixing semantics, then you probably dont want to be testing that with freshly written buggy codegen code.

I don't think there's a big pressure to merge this, or do something regarding this. It can be tackled in the future.