4 ms·

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

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.

__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.