It came to my attention that the status of the strictEquality feature falls into a grey zone regarding its stability [1][2]. The feature predates the current SIP process and the introduction of @experimental. It hasn’t been approved by the committee but, at the same time, it’s not marked as experimental and I can’t locate any mention of it being experimental in either the code or the documentation.
The feature is critical for the usability of opaque types given that equality leaks the internal representation of aliased types. It’s currently widely adopted by the community and is a key feature for Kyo’s unboxed representations like Maybe, an alternative to Option, and the pending type itself, which is Kyo’s unboxed monad implementation.
I couldn’t locate clear guidance on how to raise this kind of issue but I’d like to submit three requests to the SIP committee:
Confirm strict equality as a stable feature
Use the proper SIP-gated procedures for improvements of the feature
Audit any other features that fall into this grey zone
We’ve been diligent in Kyo’s development to ensure the project doesn’t rely on any experimental features. Having a key feature in a grey zone undermines the guarantees we’ve relied upon so far.
Yes! An audit has been on the mind of the SIP committee for some time and I expect that we’ll make significant progress this Fall. There are quite a few implicitly and explicitly experimental features that lack a SIP. Another issue is that we do not have the resources to write the SIPs for them.
We are probably going to request community input on which features are the most sought after. And given our lack of resources, the community will also have to step up and write the SIPs for the features it cares about. Having said that,
sounds like now is a good time to make it an official SIP.
Is strictEquality documented anywhere as experimental? I couldn’t locate any references other than Seth’s messages. I’m a bit confused by the lack of confirmation of the feature’s stability and indication that other features not marked as experimental might fall into the same situation.
Isn’t the implication that Scala 3 can not be relied regarding stability given features not marked as experimental can be arbitrarily deemed not stable by the SIP committee? Kyo has been on Scala Next for a long time and my expectation was that the project could finally have stability guarantees with the upcoming LTS, does this mean my expectation is incorrect?
From what we have checked internally `strictEquality` is an exception and because of that changing it will or, in very unlikely scenario, removing it would require extensive communications and will not be done lightly.
However the most likely scenario (as the feature doesn’t seem to be controversial) is that the SIP process will be used to make sure the feature is well documented and the expected use cases are ironed out.
I understand that a project with such a large scope and executed over a long span like Scala 3 can produce situations like this one with strictEquality but I hope you’re able to appreciate how it puts Scala 3’s stability into question.
If a feature without any indication of being experimental can be determined experimental, what prevents the same process of reaching other features? It opens all work in the time period without a proper SIP process, which was a significant chunk of foundational work if I’m not mistaken, to be revisited under the same angle and at the discretion of the SIP committee, which has a narrow representation of the community.
Would it be possible to address this issue before the 3.9 LTS release with a confirmation that other features not marked as experimental aren’t at risk of being deemed experimental?
No other features fall in the same category as strictEquality. No feature will be deemed experimental that is currently stable. And because strictEquality is not marked as experimental we might not be able to remove it or change significantly even. From the code perspective it is stable and will most likely be treated as such when dealing with related failures.
If we ever decide that it should be removed, I think the only thing we will be able to do is to deprecate it as there is enough code in the wild that would be broken by the removal. This is however extremely unlikely and even then we would make sure that any impact on user code is minimal.
The most likely scenario is that the feature would be accepted almost the same as it is currently. It’s pretty safe feature and only available under a language flag without a huge impact on the community otherwise.
We have been very proactive making sure that anything covered by the community build is taken into account with any significant changes. This will not change.
this feature was developed as something matching experimental flags/imports use cases
however, this feature precedesexperimental features
as such it was not developed within the framework reserved for experimental features as it was shipped before such concept was defined
if one retroactively moved it into experimental, with all the guidelines such features follows, existing code would be broken, or least existing guarantees would be broken
so it exists as a “semi-experimental” leftover from before Scala 3 invented the current approach to experimental features
however, since it is not “experimental” in the official way, there is no way of removing that thing according to the internal rules
so it is effectively “undocumented feature, specified by reference implementation” (until SIP appears) rather than experimental feature.
tl;dr treat it as undocumented feature, community build makes sure it keeps working for all current adopters, before an official SIP announces it to the world