ㅤㅤ
It is not allowed and the issue you’ve found will be fixed in an upcoming release.
Thanks for your bug report.
If you can share more about which types you’re trying to cast between I can try to help find a future-proof solution
Instead of posting all my use cases at once, i will try to go through them one by one. I will also try to show minimal examples so you don’t need to read through tons of irrelevant code.
My Issue:
Mutable members in parametric classes are not yet implemented.(3502)
Example:
list_node(t: type):=class():
var Data: t #Error
GetData(): t =
Data
My Workaround:
list_node_base:=class<abstract>:
var Data: any
GetData(): any =
Data
list_node(t: type):=class(list_node_base):
GetData<override>(): t =
(super:)GetData()
SetData(InData: t): void =
set Data = InData
So this supplies a very important feature in this context - mutable members for parametric classes.
I use this workaround basically everywhere and think there isn’t an actual way to do that.
I could in theory convert that parametric class into a non-parametric one and copy and paste it hundreds of times for all kind of types, but do not consider this a good solution.
I use that in my parametric linked list class which has around 300 lines of code despite being parametric and using this workaround. Having a linked list for a few basic function and class types would easily lead to 10.000 lines of copy pasted and hardly maintainable code.
Edt.: For a more extensive example on this topic, refer to Linked Lists in Verse | Epic Developer Community (epicgames.com) and try to make this a parametric class instead of using any
as Data type.
In case there is no future-proof solution for mutable members in parametric classes, are we perhaps allowed to use this in the meantime? If we get that feature, then i would also prefer using the official feature instead, but for now, i could not find any alternative solution.
#push
It has been almost two weeks since i created this post, so I assume that I won’t receive a reply anymore. My only solution so far is to analyze the code and convert every parametric with mutable member into a non-parametric class.
While this may sound easy, I have other parametric classes that also utilize my parametric with mutable member. This means that I’ll need to convert those classes into multiple hard-typed ones as well, and the complexity increases exponentially.
Additionally, I have normal parametric functions that also use those parametric classes. Consequently, I would need to split those into many different functions.
At this point, I believe the only ‘viable’ solution would be to write a parser myself that handles this, because otherwise, all my work from the last couple of months will be lost as soon as this bug is fixed without substitution.
All this still doesn’t include that i would also need to substitute every usage of the parametric functions and classes in my normal code.
Since I don’t know if we will get mutable members before this is fixed, it might be possible that all my effort to find a workaround will be wasted anyway.
I guess I will just say goodbye with a heavy heart, since pushing this further does not look promising. In case we get mutable members, feel free to let me know, as I would love to come back to Verse.
Cool. Still no reply after 1½ months. Now I’m kinda glad that I stopped reporting any new unintended features other than this.