i checked my relative big project, find 2 bugs in specs, which test nothing, because always pass.

I just found one boring case (not a deal breaker):

[1, "1", true, "true"].includes?(1_i64)

• It passes if I specify all 1_i8, 1_i16 (boring but okayish).
• The compiler crashes if I try [1 as Int, "1"] with "Bug: trying to upcast Int <- Int32".
• The compiler fails for [1 as Int] with "can't use Int as generic type argument yet".

Yes, the only cases I found it "broke" was when different int/float types, so it shouldn't be that terrible (you can always to_i) and will help catch real mistakes. The as Int is probably an unrelated bug.

i think better extend restriction to T?, because nil is common case of no value.

example:

# seems better
if v = bla[x]?
  p v
end

# than
if x && (v = bla[x]?)
  p v
end

# checking for x here make no sense

in my project i was need to add 10 times this check.

@kostya Yes, in a project of mine I also had this issue. T? doesn't sound that bad, leaking a nil value there is probably safe.

also spend some time to find this bug:

b = BitArray.new(10000)
if b[100] == 0
  ...
end

condition always false because comparing different types. i think crystal at least can show the warning.

Bump?

@kirbyfan64 Not sure what the best thing to do here would be. Maybe nil should also be accepted as an argument in []? methods.

Sorry I've been playing around with clojure lately.
if we had

class Object
  def in(a)
    a[self]?
  end
end

We could write key.in(hash) or key.try &.in(hash)
But it reads awfully probably.

If we accept K? as key argument for #[]? methods then we remove the change of using nil as a key which is kind of drastic, but I could accept. But most important it will prevent bubbling errors when more complex expressions used in the key are nilable without the awareness of the user.

Maybe is ok to use K? for #[]?. And K for #[] . But we should guarantee that obj[nil] = x => obj[nil]? = x

:(

@kirbyfan64 #2996 ;-)