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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
