The current state of communication regarding certain restrictions and disabled features in Verse is rather opaque, leading to confusion and frustration among users. For instance, let’s take the bug related to overriding mutable members as an example. When attempting to override a mutable, users encounter a cryptic error message that provides little insight into the underlying issue:
base_class:=class:
var X: base_class
sub_class:=class(base_class):
var X<override>: sub_class
Error:
This overriding data definition must be a subtype of the definition it tried to override: localhost.ProjectName.base_class.X(3602)
This error, initially perplexing, is later revealed to be indicating an intentionally disabled feature when delving deeper into it. The feature allowing the override was disabled because it would permit casting Value: any to int , a capability deemed undesirable:
base_class:=class:
var X: any
sub_class:=class(base_class):
var X<override>: int = 0
CastAnyToInt(Value: any):int =
SubClass:=sub_class{}
set base_class(SubClass).X = Value
return SubClass.X #Accessing Value: any as int.
The lack of explicit communication on intentional restrictions and disabled features can mislead users into perceiving them as bugs. This miscommunication is exacerbated by the compiler’s cryptic error messages, which provide little context as to why certain functionalities are disabled. Consequently, users may submit bug reports that go unanswered.
I am lead to believe, that the current communication strategy is to not reveal anything as restriction and disguise those as bugs or future expansions. I also count the lack of casting and mutable members for parametric classes into this.
A more transparent and informative communication strategy from the Verse team is essential to help users differentiate between intentional restrictions and actual issues. This would foster a more collaborative and understanding environment, reducing the likelihood of erroneous bug reports and frustration within the user community.