Hi all! Various suggestions for enhancing API usability have come up in a few different public channels and personal conversations, so we thought it would be a good idea to talk a little more about our intent in a centralized place. It is no secret that jumping into all of the new high-performance APIs can be challenging! There is a lot of new information to learn, and users are still responsible for managing a lot of complexity and boilerplate code themselves, even in simple use cases. While many factors contribute to how easy it is to learn and use things like ECS, API usability is a major one. To help focus our efforts on this front, we've tried to come up with a more structured approach to evaluating our different usability affordances, so we can identify which ones merit continuation/development, which areas of the API are lacking, and so on. I won't go into full detail here, but it includes things like How much information developers need to keep in mind for a given task How well it conforms to idiomatic C# How quickly developers get feedback on the correctness of their code How it can mitigate integration discontinuity as developers need more manual control Applying our usability criteria internally has already helped us identify some areas to clean up, as well as proposals that weren't helping us move toward our goal of making it easier to write correct, high-performance code than it is to write non-performant code. We'll use this thread to try to keep you up-to-date about our plans. Ref Returns It has been suggested in some places that ref returns could be used to help minimize typing. Code (CSharp): // today you need to do something like this var position = Positions[index]; position.Value.y = someValue; Positions[index] = position; // ref returns would enable something like this Positions[index].Value.y = someValue; We have currently decided against pursuing this affordance for a few of reasons, such as: It would not be possible to do ref returns with elements in an SOA array, which introduces more inconsistencies in language feature support within a single codebase, and would increase the refactoring burden when migrating to NativeArraySOA It provides little advantage over the status quo (e.g., it is fairly idiomatic C#, and developers currently have to do copy/modify/set of structs in MonoBehaviour C# code; the change would only save 2 lines of typing per struct type) We would have to statically analyze for safe usage, which is doable, but there are other more impactful places for us to invest in enhancements right now Instead, our goal is to make more code look like IJobProcessComponentData, which bypasses the annoyance introduced by indexing.