T.let gives unexpected behavior with instance variables about sorbet HOT 4 CLOSED

As I explained on Slack, this is not unique to instance variables, this is sort of just how variable assignments work. As long as the assignment to a "pinned" variable (a variable with an explicitly declared type) is compatible with the type it was pinned to, Sorbet will use the more narrow type of the variable if it is ever assigned to a second time.

Input

→ View on sorbet.run

# typed: true
extend T::Sig

sig { void }
def lookup_for_me
  x = T.let(0, Integer)
  x = T.unsafe('')
  T.reveal_type(x)
end

Observed output

editor.rb:8: Revealed type: T.untyped https://srb.help/7014
     8 |  T.reveal_type(x)
          ^^^^^^^^^^^^^^^^
  Got T.untyped originating from:
    editor.rb:7:
     7 |  x = T.unsafe('')
              ^^^^^^^^^^^^
Errors: 1

The issue here is simply that T.untyped is a subtype of all types, which is unsound but just the way that Sorbet works.

There are two separate issues you raise, which ought to be tracked separately:

1. Reporting a "usage of untyped" warning if the usage happens nested somewhere in the type, like T::Array[T.untyped] <: T::Array[Integer], instead of at the top level, like T.untyped <: T::Array[Integer].

   #7706

2. Adding a way to opt into this information in the srb tc output, because it is currently only available in editors.

   #7707

from sorbet.

I don't understand this resolution. The assignment explicitly specifies type parameters for the T::Hash, but those are thrown away. As a user, this makes no sense.

from sorbet.

If nothing else, this should be a clear sign that your documentation needs to be much clearer about how T.let works.

from sorbet.

There is some difference between instance variables and non-instance-variables here. In this example, the T.let is being respected when it should not be. As opposed to the original issue, which is where T.let is incorrectly (appearing to a novice to be) ignored.

from sorbet.