# Discussion: A potential solution to the anytype problem

**URL:** <https://ziggit.dev/t/discussion-a-potential-solution-to-the-anytype-problem/16259>\
**Category:** Brainstorming\
**Tags:** language\
**Created:** [June 20, 2026, 1:23am UTC](https://ziggit.dev/t/discussion-a-potential-solution-to-the-anytype-problem/16259 "2026-06-20T01:23:55Z")\
**Posts on this page:** 1\
**Showing post:** 22

<div class="post-metadata">

**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\
**Post date:** [June 20, 2026, 1:18pm UTC](https://ziggit.dev/t/discussion-a-potential-solution-to-the-anytype-problem/16259/22 "2026-06-20T13:18:41Z")

</div>

> [@Tallis-Larsen](#):
>
> For whatever reason, the #Brainstorming category doesn’t appear in the list of category options. I guess I don’t have permission to post there?

It was an attempt to reduce the number of fresh #Brainstorming topics created by very new users, which often haven’t read any existing topics, suggesting things that have been discussed a lot already.

This topic especially seems like another iteration of parts of these topics (ordered in reverse chronological order):

- [`anyerror` is a bad practice](https://ziggit.dev/t/anyerror-is-a-bad-practice/13045) (also about anytype)
- [Traits for Static Dispatch](https://ziggit.dev/t/traits-for-static-dispatch/10819)
- [Can we have compile-time, zero cost interfaces?](https://ziggit.dev/t/can-we-have-compile-time-zero-cost-interfaces/11120)
- [An Alternative to `anytype` Duck-Typing](https://ziggit.dev/t/an-alternative-to-anytype-duck-typing/7814)
- [A better anytype?](https://ziggit.dev/t/a-better-anytype/7581)
- [Unreadable anytype](https://ziggit.dev/t/unreadable-anytype/6993)
- [Implementing Generic Concepts on Function Declarations](https://ziggit.dev/t/implementing-generic-concepts-on-function-declarations/1490)
- and probably a few others…

* * *

And here some quotes I agree with:

> [@A better anytype?](https://ziggit.dev/t/a-better-anytype/7581/3):
>
> I personally think that it is also a strength that anytype doesn’t require type constraints. For example in your case you are over-constraining the add function. You want a type that has the + operator, but you constraining it to runtime integers and runtime floats. But @Vector types as well as comptime\_int and comptime\_float also support +. I think in this case it actually hurts readability to have this complex validation function. Furthermore I think the error message provided by the compi…

> [@A better anytype?](https://ziggit.dev/t/a-better-anytype/7581/7):
>
> I think anytype is fine as it is, and cannot be improved without changing other parts of the language and making it more complicated. Maybe the introduction of some kind of compile time interfacese/traits would help, but this would fundamentally change the language and it will produce other problems elsewhere (e.g. consider 2 different libraries which both have a different declaration of the same interface).

---

_[View the full topic](https://ziggit.dev/t/discussion-a-potential-solution-to-the-anytype-problem/16259)._