4 ms·

Our goal with new Sorbet versions is to break things where it makes sense (fix bugs, improve types for the standard library) which sometimes introduces new type

by jez 5y ago

Our goal with new Sorbet versions is to break things where it makes sense (fix bugs, improve types for the standard library) which sometimes introduces new type errors in projects using Sorbet. But wherever possible, we try to build autocorrects that allow for fixing or silencing those breakages. One little known feature here that works mostly well right now but could definitely be better is the `--suggest-unsafe` [1] flag, which will attempt to insert `T.unsafe(...)` in places in the program where there was a type error. Then in places where we improved Sorbet so that it no longer thought something was untyped, and started reporting errors downstream, you could run `bundle exec srb tc --autocorrect --suggest-unsafe` once after upgrading, and commit or delete the autocorrects as desired. It isn't a goal to have some sort of v1.0 milestone where new releases will not introduce type errors to a codebase that doesn't have any, which is I think what you're asking about. [1]: https://github.com/sorbet/sorbet/blob/master/main/options/options.cc#L473 https://github.com/sorbet/sorbet/blob/master/main/options/op... (edited to clarify phrasing in response to child comment)

jrochkind1 5y ago
Thanks for the info! I don't use sorbet myself yet (although I am a ruby user), so this is not coming from any kind of educated basis, just an outside observer being curious, but I'm curious: > We don't currently have a plan or a desire to get to a state where upgrading to a new Sorbet version will not introduce new errors on a codebase that previously type checked, which is what I think you might imply you want out of a v1.0 release. That surprises me enough that I had to read it a couple times to make sure I was understanding how all the "not"s came out. I'd think that would be a thing you would straightforwardly want out of at type checker, the thing you said you don't have a plan or desire for. I'm interested in hearing more about why not, here or a link to somewhere else.
- __s 5y ago
  The "not" is that they want freedom to make the type checker more strict, ie expand it to detect type errors it failed to detect previously
- jez 5y ago
  Here's an example PR from a few days ago where someone contributed an improvement to the type definitions Sorbet maintains for the standard library: https://github.com/sorbet/sorbet/pull/5024 https://github.com/sorbet/sorbet/pull/5024 By adding those type definitions, any downstream projects using Sorbet that happened to use those definitions incorrectly will start to see new type errors. Here's another example: https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3ASig%0A%0Asig%20%7Bparams%28x%3A%20%7Bkey1%3A%20Integer%7D%29.void%7D%0Adef%20foo%28x%29%0A%20%20x%5B%3Akey2%5D%20%23%20no%20error!%0Aend https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A... This example shows a bug in how Sorbet handles shape types, that we definitely want to fix in the future but haven't had the time to yet. When we fix that, any project using shape types incorrectly will suddenly have new type errors.

by jez 5y ago

jrochkind1 5y ago

Thanks for the info! I don't use sorbet myself yet (although I am a ruby user), so this is not coming from any kind of educated basis, just an outside observer being curious, but I'm curious: > We don't currently have a plan or a desire to get to a state where upgrading to a new Sorbet version will not introduce new errors on a codebase that previously type checked, which is what I think you might imply you want out of a v1.0 release. That surprises me enough that I had to read it a couple times to make sure I was understanding how all the "not"s came out. I'd think that would be a thing you would straightforwardly want out of at type checker, the thing you said you don't have a plan or desire for. I'm interested in hearing more about why not, here or a link to somewhere else.

__s 5y ago
The "not" is that they want freedom to make the type checker more strict, ie expand it to detect type errors it failed to detect previously
jez 5y ago
Here's an example PR from a few days ago where someone contributed an improvement to the type definitions Sorbet maintains for the standard library: https://github.com/sorbet/sorbet/pull/5024 https://github.com/sorbet/sorbet/pull/5024 By adding those type definitions, any downstream projects using Sorbet that happened to use those definitions incorrectly will start to see new type errors. Here's another example: https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3ASig%0A%0Asig%20%7Bparams%28x%3A%20%7Bkey1%3A%20Integer%7D%29.void%7D%0Adef%20foo%28x%29%0A%20%20x%5B%3Akey2%5D%20%23%20no%20error!%0Aend https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A... This example shows a bug in how Sorbet handles shape types, that we definitely want to fix in the future but haven't had the time to yet. When we fix that, any project using shape types incorrectly will suddenly have new type errors.