I'm perfectly fine with naming we had all this time, but in a new era AI writes most of the code, and I think having a naming parity with JavaScript is more important. For example, this proposal was inspired by the Claude Code session where it was doing bindings for napi-rs and it used Nullable.t type thinking that its value is null, like in TS. I had to correct it myself, saying that it should use a more correct Null.t type.
Additionally, Null.t by itself is already confusing, making me subconsciously think that it's just a null value type.
Proposed migration plan
Since this is a very big breaking change and updating both modules at the same time will be an issue because it might silently change generated JavaScript code, I think we must approach it in multiple major releases. And because of this, start earlier. Here is the proposed plan.
- In next v12 minor we deprecate
Nullable module in favor of the new Nullish module
- In v13 we we remove
Nullable in favor of Nullish
- In v14 we deprecate
Null module in favor of Nullable - I think there should be a whole major version without Nullable module to prevent issues during migration
To accelerate the change, we can add a feature flag in ReScript config which would allow us to explicitly force the migration: Null->Nullable, Nullable->Nullish
Let me know what you think.
I'm perfectly fine with naming we had all this time, but in a new era AI writes most of the code, and I think having a naming parity with JavaScript is more important. For example, this proposal was inspired by the Claude Code session where it was doing bindings for napi-rs and it used Nullable.t type thinking that its value is null, like in TS. I had to correct it myself, saying that it should use a more correct Null.t type.
Additionally, Null.t by itself is already confusing, making me subconsciously think that it's just a
nullvalue type.Proposed migration plan
Since this is a very big breaking change and updating both modules at the same time will be an issue because it might silently change generated JavaScript code, I think we must approach it in multiple major releases. And because of this, start earlier. Here is the proposed plan.
Nullablemodule in favor of the newNullishmoduleNullablein favor ofNullishNullmodule in favor ofNullable- I think there should be a whole major version withoutNullablemodule to prevent issues during migrationTo accelerate the change, we can add a feature flag in ReScript config which would allow us to explicitly force the migration: Null->Nullable, Nullable->Nullish
Let me know what you think.