09:17 <FromGitter> <domgetter> Can a numeric variable change types at runtime? I have a variable such that `puts grid_offset_y.class` prints out `Int32` on one line, and then a few lines later, `puts grid_offset_y.class` prints out `UInt16`. Between the two puts there is an assignment of `grid_offset_y = y + cel.y_offset` where `y` is a UInt16, and `cel.y_offset` is an Int16. Is this expected?

09:23 <FromGitter> <domgetter> For now I've wrapped the RHS of the assignment in a `.to_i32!` but I didn't think I had to do that.

10:14 <FromGitter> <moe:busyloop.net> yup. you re-assigned it, so it then points to the new value. ⏎ ⏎ https://carc.in/#/r/eeoy

11:11 <FromGitter> <domgetter> So is Crystal not statically typed?

11:47 <FromGitter> <moe:busyloop.net> it is, but it tries to stay out of your way as much as possible

11:48 <FromGitter> <moe:busyloop.net> if you want to reassign vars, it lets you do that - unless/until you create a type-conflict that it can't resolve, then it forces you to be explicit

11:53 <FromGitter> <moe:busyloop.net> that's what makes it so fun to write. in other languages you have to declare types everywhere, which gets noisy and annoying quick. ⏎ in crystal the compiler does most of this work for you. in most places you can omit the type and it will infer it.

12:04 <FromGitter> <domgetter> I do like the type inference, but I thought that a variable's type couldn't change over time, and that the compiler would infer something like (UInt16 | Int32) instead of making it an Int32 at one point, and then a UInt32 later.

12:07 <FromGitter> <moe:busyloop.net> it does such things in certain scenarios. ⏎ but in yours there is no ambiguity.

12:08 <FromGitter> <domgetter> Is it possible to puts the type of the variable instead of the class of the object to which it currently refers?

12:09 <FromGitter> <moe:busyloop.net> https://carc.in/#/r/eerd

12:09 <FromGitter> <moe:busyloop.net> sure :)

12:10 <FromGitter> <moe:busyloop.net> you can also assign at the same time: `a : Int32 = 5`

12:12 <FromGitter> <domgetter> Hmm when I write `grid_offset_y : (UInt16 | Int32) = 0` it still only ever prints UInt16 or Int32 when I puts the .class or the typeof().

12:14 <FromGitter> <moe:busyloop.net> When you use the .class or typeof() method in Crystal, it returns the class of the object at runtime, not the type that was specified in the variable declaration. The type specified in the variable declaration is used at compile-time for type checking, but it does not affect the value of the object at runtime. ⏎ ⏎ In your example, the variable grid_offset_y is defined as a union of UInt16 and

12:14 <FromGitter> ... Int32, but at runtime, it can only ever be an instance of one of those classes. The .class or typeof() method will return the class of the actual object that is assigned to the variable, which will be either UInt16 or Int32, not the union of the two.

12:14 <FromGitter> <moe:busyloop.net> (chatgpt ftw)

12:15 <FromGitter> <domgetter> My question is, is there a way to see that the variable is that type union at runtime?

12:16 <FromGitter> <moe:busyloop.net> sec, conferring with gpt

12:18 <FromGitter> <moe:busyloop.net> well, the tldr seems to be: nope

12:19 <FromGitter> <moe:busyloop.net> or rather, you can do: `var.is_a?(Type.union(UInt16, Int32))` - but the question is why would you want to

12:19 <FromGitter> <domgetter> yeah if I already knew it, it would be moot to ask

12:20 <FromGitter> <moe:busyloop.net> exactly ;)

12:20 <FromGitter> <domgetter> I got tripped up in this case because I didn't know it was inferred to a union

12:22 <FromGitter> <moe:busyloop.net> yep, unions can be confusing. but (without knowing your code) my first question about your particular case would be: why is the offset sometimes an Int32 and sometimes an UInt16?

12:29 <FromGitter> <domgetter> a `cel.y_offset` is a value from an aseprite project file which is a 16bit signed integer for the current image's pixel data offset to the top left of the canvas, and is signed because pixels can be "off-canvas", `y` is the coordinate within a current cel so it's unsigned since pixel data within a cel can't be "off-cel", and grid_offset_y is a value I created to do analysis with the underlying pixel data in

12:29 <FromGitter> ... order to slice them into subsprites for a game, so I had no need or want to limit it to 16bit.

12:52 <FromGitter> <moe:busyloop.net> hm yea, then you have to cast it somewhere to the type that your game uses - exactly what the compiler asked you to do above :)

12:53 <FromGitter> <moe:busyloop.net> if that causes friction in multiple places then maybe you can move the casting to some "earlier" place (e.g. when the sprite is loaded)

13:46 <FromGitter> <Blacksmoke16> you can add type restrictions to local vars. So yes it *can* be statically typed, but its not a requirement in some cases, like local vars

23:48 <FromGitter> <domgetter> The way I see it now is that it is statically typed to the union type that I didn't understand. Is that a good way of looking at it?