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

empty namedtuple is not a leaf #52

Closed
CarloLucibello opened this issue Nov 25, 2022 · 6 comments
Closed

empty namedtuple is not a leaf #52

CarloLucibello opened this issue Nov 25, 2022 · 6 comments
Milestone

Comments

@CarloLucibello
Copy link
Member

julia> Functors.isleaf((;))
false

I guess we should consider this a bug.

@ToucheSir
Copy link
Member

Discussion about this was in #36 (comment). Can you see any scenarios where having this be true would be helpful?

@CarloLucibello
Copy link
Member Author

CarloLucibello commented Nov 25, 2022

I didn't know about #36. I didn't think the question thoroughly yet but
right now on master everything is a leaf by default, which corresponds to children(x) == ().
Moving to the opposite default in #51 where everything is a tree,
one of the possible opt-out options one can choose is
@functor MyType () but since this gives children(x) == (;) MyType is not considered a leaf.

Maybe we should just have:

isleaf(x) = isempty(children(x))

?

Or I could introduce in #51 a @nofunctor MyT macro that does functor(x::MyT) = (), _ -> x. I think this should be done in any case.

This was referenced Nov 25, 2022
@ToucheSir
Copy link
Member

ToucheSir commented Nov 26, 2022

The problem with using isempty is that children([]) == true. If anything, we would want to choose a type that has fewer methods defined and thus won't accidentally show up as a non-leaf. Nothing comes to mind, but if that's too generic then a custom NoChildren singleton type could work as well.

@CarloLucibello
Copy link
Member Author

Assuming we want to stop specialcasing the empty tuple for isleaf, maybe better use a custom singleton rather than nothing so that we can make it (trivially) mappable.

@CarloLucibello CarloLucibello added this to the v0.5 milestone Oct 21, 2024
@CarloLucibello
Copy link
Member Author

before tagging v0.5 we should take a decision on this issue

@CarloLucibello
Copy link
Member Author

Since no one actually complained about this, we can just keep things as they are.

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

Successfully merging a pull request may close this issue.

2 participants