Thanks for the clarification. I understand what you are saying, but I would love to see some changes to rom in the future.
I think it would be much better if it acted more like a type qualifier rather than a type. The function overloading is nice, but now I am required to have two functions for every function that takes a rom parameter. Not only does this unecessarily require extra code space, but it also means that I have two functions that differ only in their parameter definitions. If I make a change to one function, I now have to remember to also change the other. This does not promote good code structure.
Maybe a good way to handle this would be to allow non-rom pointers to be passed in rom parameter locations (much like the const qualifier). Then the compiler could decide the correct way to access the memory.
In addition, I would like to see rom pointers support pointer arithmetic and dereferencing with '*'.
Using rom with other types (including structs and unions) and non-pointer variables would be another great feature addition.
Perhaps a better way to handle this would be to use rom solely as a storage qualifier when defining variables to be stored in program memory. For instance, you could use "rom const char *s ="Hello". This would simply force "Hello" to be stored in program memory and s could be treated as "const char *" throughout the rest of the code.
I may be missing something, but why not completely get rid of the rom qualifier and place all const variables in program memory? Don't all other compilers use this method? As an application developer, this would be my preferred solution.