Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add deref_or and destruct to Nullable, add destruct to Box #3854

Closed
1 of 2 tasks
enitrat opened this issue Aug 7, 2023 · 4 comments · Fixed by #4037
Closed
1 of 2 tasks

feat: Add deref_or and destruct to Nullable, add destruct to Box #3854

enitrat opened this issue Aug 7, 2023 · 4 comments · Fixed by #4037
Labels
enhancement New feature or request

Comments

@enitrat
Copy link
Contributor

enitrat commented Aug 7, 2023

Feature Request

  • Add a fn deref(self: Nullable<T>, value: T) -> T to NullableTrait to either deref a Nullable or return the provided value
  • Add the Destruct implementation in nullable.cairo
  • Add the Destruct implementation in box.cairo
    Describe the Feature Request

Describe Preferred Solution

    fn deref_or(self: Nullable<T>, default: T) -> T {
        match match_nullable(self) {
            FromNullableResult::Null => default,
            FromNullableResult::NotNull(value) => value.unbox(),
        }
    }
impl NullableDestruct<T, impl TDestruct: Destruct<T>> of Destruct<Nullable<T>> {
    fn destruct(self: Nullable<T>) nopanic {}
}
impl BoxDestruct<T, impl TDestruct: Destruct<T>> of Destruct<Box<T>> {
    fn destruct(self: Box<T>) nopanic {}
}

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

  • Yes
  • No
@enitrat enitrat added the enhancement New feature or request label Aug 7, 2023
@enitrat enitrat changed the title feat: Add deref_or and destruct to Nullable feat: Add deref_or and destruct to Nullable, add destruct to Box Aug 7, 2023
@orizi
Copy link
Collaborator

orizi commented Aug 7, 2023

The destruct part would probably require additional features in the language,
Since we'd have several implementations of Destruct in the droppable cases (as Drop creates a default Destruct impl)
Solutions:

  1. Impl ranking for when inferring a type
  2. Enforcing not having a particular impl available (in this case, when implementing destruct, no Drop<T> can be available.

@enitrat
Copy link
Contributor Author

enitrat commented Aug 8, 2023

Hm, I don't really get it. What would be the correct way of deriving Destruct on a struct that contains Box or Nullable then? I naively added empty destruct functions as provided in the example here.

@orizi
Copy link
Collaborator

orizi commented Aug 8, 2023

you'd need to have a specific one - not a generic one.

The issue is this:

If you have both a Drop and Destruct for the nullable - type, anywhere that requires a destruct, would have 2 impls of destruct for nullable, and would not know which one to choose.

Currently - just adding a specific Destruct impl for the nullable<Specific> you have would work.

@enitrat
Copy link
Contributor Author

enitrat commented Aug 8, 2023

Okay, indeed that's whay I ended up doing; thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants