04:45 <f1refly> hightower: Ohhh, I missed that! Thank you!

10:47 <postmodern> is there a helper method in Iterator for returning a single value, then stopping on next iteration?

11:16 <postmodern> hmm wtf, why can't I use enum values in a case ... in statement?

11:16 <postmodern> enums are supposed to be exhaustive, no?

12:07 <postmodern> the compiler's `if var.nil? ... elsif var.method() ...` awareness could use some work

12:42 <FromGitter> <Blacksmoke16> Do you have an example of it not working?

13:04 <postmodern> Blacksmoke16, https://carc.in/#/r/by7q

13:05 <FromGitter> <Blacksmoke16> 1) you dont need to define those `one?` method and stuff, they're added automatically ⏎ 2) it would probably work if you assigned the ivar to a variable first

13:07 <FromGitter> <Blacksmoke16> https://carc.in/#/r/by7t

13:08 <FromGitter> <Blacksmoke16> https://crystal-lang.org/reference/syntax_and_semantics/if_var.html#limitations

13:10 <postmodern> Blacksmoke16, ah case style. I also noticed `if/else` worked, but `if / elsif` does not get caught by the compiler.

13:11 <postmodern> Blacksmoke16, after the initial nil check, the variable should be considered not-nil in all following branches

13:11 <FromGitter> <Blacksmoke16> not when you do `@ivar.nil?`

13:12 <postmodern> Blacksmoke16, after that branch, iff it's false

13:13 <postmodern> i'm guessing we just need better compiler logic for identifying if/elsif branches

13:50 <yxhuvud> No, if you check against an ivar, then some other fiber may change the value underneath the feet of the code.

16:05 <postmodern> yxhuvud, that's a valid concern. however `if @ivar.nil? ... else ...` works, but `if @ivar.nil? ... elsif ...` does not, which seems inconsistent.

16:06 <FromGitter> <Blacksmoke16> got an example that shows this behavior?

16:09 <postmodern> also another method could somehow modify the ivars in the current fiber once inside a `if !@ivar.nil?` or `case @ivar` block

16:10 <FromGitter> <Blacksmoke16> right, which is the basis of the limitation

18:26 <postmodern> perhaps in the future it will be possible to lock an ivars value for a period of time to ensure consistency

18:26 <FromGitter> <Blacksmoke16> you already can do that `value = @ivar`

18:26 <FromGitter> <Blacksmoke16> tada