Ok, type bound. You can still easily pass around data whose type is not concretely defined at the compilation step. Unless you’re arguing that the dynamic type is actually static, in which case this whole conversation seems semantically pointless.

2 hours ago I answered it already. If you're another person who wants to convince me that Rust has same thing as Dart's "dynamic" type, then please make my code example to compile (without modifications, for literally ANY type, as in Dart) and I will say I was wrong.

Dart type or rust type? They refer to different things, which is the source of the confusion, but they're both strongly typed.

In any case, you're moving the goal post from "concrete type at compile time" to "can represent any type", which is inherently going to be specific to how the language defines types. This is not an especially useful type of dynamic representation so I'm not sure why it would be desirable.

There is no confusion. Rust doesn't have dynamic type and Dart does. That's it.

Any talks about special traits in Rust are offtopic, while code I wrote as example can't be compiled in Rust and can perfectly work in Dart.

I wasn't trying to argue about words or terms, I was trying to say the gist: Dart has dynamic type, so you can send to your function any type and this function will just use it, without any downcasting - language will take care about it; and Rust doesn't have such type: you can't even compile code which is trying to work with variables like you can do in dynamic languages.

But then all of that useless arguing... It's really funny when I see how people are trying to prove that Rust has same dynamic type as Dart. The very nature of these languages is different.

Pointers are certainly types in Rust, and although it's of course true that the Any trait is not itself a type, a reference to an Any trait (which is what you'd actually pass around) is a type.

Well, you can repeat it many times but it will not become true. I gave you link to the list of Rust types. Pointers are pointers, not types. Traits can have any name, their names mean nothing.

https://doc.rust-lang.org/book/first-edition/raw-pointers.ht...

    *const u32

(for example) is a clearly a Rust type -- a const pointer to an unsigned 32-bit integer, analogous to

    const uint32_t *p

in C/C++.

I'm not sure what you mean about trait names. The purpose of the Any trait is to make it possible to pass around values of any type and dynamically downcast them, as the documentation indicates. That is a safe analogue of casting a void pointer to another type.

To be dynamic, "Any" should be able to represent literally ANY type. As you can find, Any is a reflection-wise trait to work with static types. It's not something what you can use when you don't know type and language will dynamically convert it. You can't write

    fn example(foo: Any) -> u32 {
        foo+55
    }

as you CAN do in dynamic languages. Do you understand me now? Or we will keep talking about unsafe extra special types?

Please remember there's a genuine human on the other end, trying to have a respectful conversation with you.

Or there is a person who is trying to prove his offtopic point by some pedantic interruptions, which are far from the main idea of discussion.

You can do that if you change it to &Any and then downcast. See the docs for examples. If the issue is that you have to downcast, then your initial claim that Rust lacks void pointers was irrelevant even if true, since you also have to downcast a void pointer in C before you can perform operations on the type that it's actually pointing to.

You can't downcast it to anything you want, it returns an Option, void pointers in C are not certainly the same, it's unsafe.

I know. That's why I said it's "a safe analogue of casting a void pointer to another type".

> If the issue is that you have to downcast

It's the difference between dynamic language and language with synthetic type for reflections.

A pointer is absolutely a type in rust.

let i: u32 = 1;

let p_imm: const u32 = &i;

Look at the const u32 in the type position.

The rust book even refers to const and mut pointers as types.

const and mut are not types, it's modifiers of mutability. On both lines type is u32z

The asterisks in leshow's comment are being lost in the formatting, since HN uses them for italicization. So the last line, for example, is:

    The rust book even refers to *const and *mut pointers as types.

I really can't believe how stupid people can be to say "const" is a type. Even if Klabnik will say it into my face it will not be true, I don't care about the book he wrote.

leshow said that

    *const u32

is a type, not that 'const' is a type. HN's formatting removed the asterisk, as it uses asterkisks for italicization.

The asterisk was formatted out. Read the book, they are types.

So you can write "let x:const = 5"? if "const" is a type.

You were just told the formatting removed the asterisk. const isn't a type, but a const pointer is, so is a mut pointer. It says so in the book AND it's in the position of a type in the code. What other information do you need to convince you that you're wrong?