tqchen commented on PR #96: URL: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1373465521
That particular RFC you were referring to is about C interface and not rust. 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. 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. That means that we apply name-spacing, naming and folder organizations for the context that is suitable for better architectural clarity and we do our best effort in our development. Such approach is not exclusive nor diminish the value of the work or an area. As we are not stating that because of other modules we should stop accepting the module. 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. Under the context of the proposal (which stated as embedded rust). This seems to be a quite reasonable actionable item to take. We are also more than welcome to suggest a change of the context to say let us discuss the general rust usage, and what the majority of such interactions are should be like. Under that context the name rust without other refinement might have been proper. And we can evaluate the architectural considerations under that context. -- 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]
