Hello, in ANSI C/C++, C#, Rust etc. there is MISSING this type of dynamic casting:
struct MyStruct { int item; };
MyStruct ms;
char dynTypeName[] = "MyStruct";
void *ptr;
ptr = &ms;
dynamic_cast<dynTypeName>(ptr)->item = 1;
Ok, it would be very useful, but missing. And My question is:
Is there an equivalent of such dynamic run-time type-casting in RUST ?
Jerry
You could use the Any trait. Questions about how to use Rust are better directed towards users.rust-lang.org, you'll find more help there. internals is for discussions around the design and implementation of The Rust Programming Language
If I understand that code correctly you want to use a runtime string as the type to cast to? If that's the case how is that supposed to typecheck? The compiler can't know that whatever type whose name is inside dynTypeName will have an item field.
... runtime string as the type to cast : YES, it is the case
Such dynamic casting would requre a hash table for the "dynamic checking" if such basic type or structure or class exists and the pointer to such type/struct/calss is given by the "ptr" variable - it is anonymous/void pointer, but valid pointer.
yes, internals is for discussions around the design and implementation of The Rust Programming Language...
I am very carefuly proposing "A change" 
or "An improvement" of currect state of Rust
This doesn't sound like a change proposal. Got me confused. Maybe reword it to say what you want to add, where this is useful, and what's the cost of the change. This way others also don't get confused
I do not know how to send "A change proposal" but such arrangement is very useful for dynamic databases ...
and the cost of change in Rust compiler ? I do not know how fast can the creator(s) add such functionality to the compiler ... months ? years ? Such functionality can move Rust to area of symbolic compilers.
Can you provide an example how such a thing would look like in assembly?
the "assembly" you mean "assembler" ? I have not assembler for Rust. The "recipe" is simple:
1/ every exe file needs a table of names of "named" variables/structs/classes
2/ using a hash table with direct addressing it is possible to get structure of pointed object and perform the run-time type-checking.
3/ Once the validity of the String is verified, the "ptr" void pointer enables to access to physical object in memory.
Assembly language. I assume you know what that is.
I'd also accept a sample ‘desugaring’ to already-existing, stable features of the language, ready to compile and try out.
yes, I understand. ... this will take ... several months ..
Dynamic Casting by name would be incredibly difficult to implement, and incredibly difficult to design, given that the static typechecker needs to know the type of the output, which it cannot if you use a dynamic string.
ok, too dificult, so what if we introduce a new type of "A TYPE" as a key-word named "dyntype", then the example will then looks like this:
struct MyStruct { int item; };
MyStruct ms;
dyntype myDynTypeVariable = typeof(MyStruct);
void *ptr;
ptr = &ms;
dynamic_cast<myDynTypeVariable>(ptr)->item = 1;
from now, everyhing will be significantly more simplified because type list of all variables is accessible for the compiler at compilation time ...
dyntype are all valid types the compiler still can't know statically know what type it's representing at compile time, hence it can't know if that type actually has an item field and what it should do to access it.The issue, though, is we still can't determine precisely the type that the output has (only perhaps what types it could be; if you can return dyntype from a function, it could be returned from an foreign code). The issue isn't the fact that the input is a string (indeed, a constexpr string would be fairly trivial to implement in some way, albeit, fairly useless since if you have a constexpr string, you can name the type directly), the issue is the fact it's only known dynamically, for which an implementation would require fully dynamic typing.
Indeed, and for a good reason! This type of programming is basically impossible to support in a statically compiled language. And if it were supported, it would almost certainly add prohibitive costs to all parts of the program, even those that do not care or want for this feature.
You can still write similarly dynamic code in Rust, of course. It just won't be as convenient as writing the same code in a language designed for more dynamic kinds of programming. That's expected: a hammer and a screwdriver are both versatile tools that are most useful for different jobs; the same is true for different programming languages. Trying to fit Rust into a JavaScript-shaped hole is not going to benefit anyone.
To write such code in Rust, you basically should make all your types a HashMap (which just makes explicit what happens under the hood in languages such as Python or JavaScript). No language change is required then, and only the parts of the program that need such dynamism need to pay the cost for it. I assume one could use some library support and proc macros to make this more convenient.
ok, so we close this "theme" .... or I will go to hell
I sure hope you won't. 
That's a bit harsh. There's no need to go to hell. What you should do is go get some formal computer science education at a university. Especially useful before you start suggesting changing a programming language.