Mousius commented on PR #96: URL: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1373696783
> I also stated reasonings on why the interface_c name was a OK choice under that the context of C, because C is a language that is mostly used for embedded space -- rust do not have that same profile, as a result when we do the development we need to consider it under the new context of rust along with the need of proposed targets. > > Under the context of rust , it is helpful to clarify the intend because rust's most common use is not only embedded language and do not come with name spacing. Rust also come with dynamic memory management, reference counting along with other things that makes other API style possible and perhaps more primarily used under non-embedded settings. C is used for a variety of use-cases and is foundational to much of the software used in larger systems (not only embedded), it includes dynamic memory management and reference counting - Python itself would not exist if C wasn't capable of this. The choices in the embedded C API make it better for environments where dynamic allocation isn't favored and with a subset of the C standard library, which is similar to `no_std` in Rust - they are targeted at the same subset. > As a result a clear naming, like interface_embedded_rust would be a clear way to signal the intent. I also do not see any inconsistency applying such organization might bought. > When looking at the consistency of the codebase. We consider the architecture in a wholistic way. > Instead we say give a proper naming and organization considering so it have clarity under the context it is in. That is overall better for the wholistic architecture and consistency in the codebase. Naming it `interface_embedded_rust`, is clearly inconsistent with `interface_c` which serves the same audience, as documented above we're using a subset of both languages in similar ways. I'm actively encouraging you to take a holistic approach and consider that both the C and Rust APIs are both designed as resource constrained variants of the broader languages. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org