You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For option Maybe returning T::to_variant() if option is some else Variant::nil()
for Result dict!("Ok" : T::to_variant() )
for Vec, returning a variant array
Vec<T> definitely has a pretty obvious implementation, alongside other obvious collections. In fact we already have a From impl to convert Array<T> into Vec<T>, though not the reverse which is weird, but i guess you can just do .iter().collect().
Result i'm a bit more unsure about. i think we should base Result on #246 when that's merged, rather than make a separate implementation.
Option will be handled by #247 as mentioned, and it makes more sense to give it a separate implementation since it's used to represent nullable values.
Would any Err(...) enumerator always map to Variant::nil()?
I don't understand what you mean there.
If V and E in Result<V,E> are both ToGodot I don't see what's lost in making the Result ToGodot as well, it can make handling Errors on the gdscript side a little more convenient.
Actually I don't really care about Result but Option and Vec are definitly something I came across making my game
changed the title [-]Feature : implement ToVariant for Vec<T>, Result<T>, Option<T> where T : ToVariant[/-][+]Feature : implement ToGodot for Vec<T>, Result<T>, Option<T> where T : ToGodot[/+]on Oct 27, 2023
Result<T,E> is either not implemented, or we just panic for Err. In the future we may support using Result as a return type, where Err prints an error to Godot or something like that.
FromGodot:
Option<T> map null => None and value => T::from_godot(value)
Vec<T> does effectively arr.iter_shared().collect()
Option always maps to a nullable variant, except when the type itself is nullable.
Vec is Array as most people would expect
Result can be used to detect errors when a function is called
Additionally we should implement Property and maybe Export for at least Option<T>, unless this causes godot to behave weirdly (such as the editor displaying weird values if you attempt to set it to the wrong value). We may consider only implementing it for Option<Variant> if that's the case.
I'm not sure about Option<Variant> though -- you would have two possible null states: None and Some(Variant::nil()).
It might be a necessity if we have an Option<T> blanket impl though...
I'm not sure about Option<Variant> though -- you would have two possible null states: None and Some(Variant::nil()). It might be a necessity if we have an Option<T> blanket impl though...
i think we'd probably implement it for each different option of Via. Since there's only a limited number of possible Via types. so we can choose to leave out Variant if we want. (kinda necessary if we want Option<Gd<T>> to be different)
Activity
Mercerenies commentedon May 8, 2023
Option
is being worked on (at least forOption<Gd<T>>
) at #240, by the way. I'm not aware of any work being done for vectors or results.astrale-sharp commentedon May 8, 2023
I'd be interested to contribute if no one is on the case yet !
lilizoey commentedon May 8, 2023
Vec<T>
definitely has a pretty obvious implementation, alongside other obvious collections. In fact we already have aFrom
impl to convertArray<T>
intoVec<T>
, though not the reverse which is weird, but i guess you can just do.iter().collect()
.Result
i'm a bit more unsure about. i think we should baseResult
on #246 when that's merged, rather than make a separate implementation.Option
will be handled by #247 as mentioned, and it makes more sense to give it a separate implementation since it's used to represent nullable values.Bromeon commentedon May 8, 2023
What would the semantics for
Result<T, E>
be?Would any
Err(...)
enumerator always map toVariant::nil()
?Also, what's the motivation behind it? Might be more explicit to use
Result::ok()
if that's desired 🤔Bromeon commentedon Jun 13, 2023
@astrale-sharp any comments? 🙂
astrale-sharp commentedon Oct 26, 2023
I don't understand what you mean there.
If
V
andE
inResult<V,E>
are bothToGodot
I don't see what's lost in making the Result ToGodot as well, it can make handling Errors on the gdscript side a little more convenient.Actually I don't really care about Result but Option and Vec are definitly something I came across making my game
[-]Feature : implement ToVariant for Vec<T>, Result<T>, Option<T> where T : ToVariant[/-][+]Feature : implement ToGodot for Vec<T>, Result<T>, Option<T> where T : ToGodot[/+]lilizoey commentedon Oct 27, 2023
Note:
ToVariant
has now been renamed/re-purposed intoToGodot
lilizoey commentedon Oct 27, 2023
Suggestion:
Assume here that
T: GodotConvert/ToGodot/FromGodot
as appropriate.GodotConvert
:Option<T>
, withVia = Variant
(unless other more specific implementation exists, such as forOption<Gd<T>>
)Vec<T>
, withVia = Array<T::Via>
Result<T, ConvertError>
, withVia = T::Via
(see MakeFromGodot
conversions fallible #467)ToGodot
:Option<T>
mapsNone => Variant::nil()
,Some(x) => x.to_variant()
Vec<T>
does effectivelyvec.iter().collect()
Result<T,E>
is either not implemented, or we just panic forErr
. In the future we may support usingResult
as a return type, whereErr
prints an error to Godot or something like that.FromGodot
:Option<T>
mapnull => None
andvalue => T::from_godot(value)
Vec<T>
does effectivelyarr.iter_shared().collect()
Result<T, ConvertError>
doesOk(T::try_from_godot(value))
(see MakeFromGodot
conversions fallible #467)We then have:
Option
always maps to a nullable variant, except when the type itself is nullable.Vec
isArray
as most people would expectResult
can be used to detect errors when a function is calledAdditionally we should implement
Property
and maybeExport
for at leastOption<T>
, unless this causes godot to behave weirdly (such as the editor displaying weird values if you attempt to set it to the wrong value). We may consider only implementing it forOption<Variant>
if that's the case.Bromeon commentedon Oct 28, 2023
Sounds good, thanks for listing it up.
I'm not sure about
Option<Variant>
though -- you would have two possible null states:None
andSome(Variant::nil())
.It might be a necessity if we have an
Option<T>
blanket impl though...lilizoey commentedon Oct 28, 2023
i think we'd probably implement it for each different option of
Via
. Since there's only a limited number of possibleVia
types. so we can choose to leave outVariant
if we want. (kinda necessary if we wantOption<Gd<T>>
to be different)9 remaining items