i see we need to make the crates to four areas (io , pure_logic , adapters , main):
the main: can only call the adapters and cant have the io operations
the adapters: can only calls the pure_logic and io
the pure_logic: can only call the the other pure_logic and cant have any target operations
the io: can only do target operations like row pointers and system io and can be called only from adapters
this idea will make the code highly portable like make it work for linux and window and macos and ios and android and also playstation and xbox and embedded and wasm and any new target without the need for refactoring the code that mean all the crate will support that by default
i see the idea will worth because imagine with this we will enforce each developer to make his crate work on every target that mean we will not need of rewriting some crates just for portability , and if the crate don't have io layer for some target we can make it without rewrite the entire crate just to add this target
i think the easy way to do that is to add this to cargo.toml
[package]
layer = "pure_logic" # compiler enforces no io or adapter calls
or layer = "io" or any thing like that , because i think this will make the ecosystem better , and thank you 
Pure logic doesn't necessarily work the same on every machine. I could write assert_eq!(0x8000_0000, 0xc000_0000_usize.wrapping_add(0xc000_0000)); and have this pure logic work perfectly on the 32-bit firmware devices I write code for, but then it'll fail on the 64-bit machines most people use. And if you want to disallow usize values, the same thing can be done with pointers, and disallowing those would break most data structures.
If you want to make this happen, a good first step would be to figure out what exactly you consider to fit in each category, how you're going to enforce that, and how this could be implemented in a backwards-compatible way (backwards compatibility can't be broken, and also if crates using your system can't use crates that don't, then that also wouldn't work). It would also help to present examples of what crates in each of those "layer"s will look like.
4 Likes
i dont know too much of that , but if you ask me how it look like , then it will be , like the io layer will have the input output of the app like syscalls and also raw pointers maybe , while the pure_logic will have the traits and impls and functions and the adapters will have the implementaions of the trait of the pure_logic using the io layer while the main will just have the main , the reason of that is to make any crate support all the target that the third party programmer want , but i want it backward compatibility then i prefer to make it as optional section in the cargo toml but still they will need to rewrite there code to fit this new standard that mean if we want it then we need to split the ecosystem , but is it good idea for new language to do that ? or not ?