Blog post: Untapped potential in Rust’s type system

Hi community,

I've spent quite some time playing around with the dynamic typing capabilities Rust offers. I found it quite interesting how far this can be taken, safely, if one is willing to handle complex type definitions.

But the article I wrote about it is already long enough, so I'll not write more here. Check it out if you are interested.

(I will gladly respond to questions and comments, although maybe a bit slow in the next couple of days. )

3 Likes

For example, Vec<Box<dyn PartialOrd>> stores a collection of pointers.

PartialOrd is not object safe though, because it has an implicit Self generic parameter.

TL;DR. I'm not sure at all what the "untapped potential" is. Your TypeId-based collection is already implemented in typemap. And this part seems incorrect:

In particular your argument about renaming parent modules does not apply, because one can create two identically-named types with identical members and layout in two different modules at the same time, and they would then appear to be the same type. That is bound to cause errors.

1 Like

As a follow up to this, you also can't rely on their layouts being the same, which means you can't use UniversalId as a straight replacement for TypeId without extra layout guarantees.

2 Likes

Is you "nuts" crate name a play on "NATS" : https://nats.io/. They both provide a pub/sub messaging system?

Oops, right, I should have taken a better example. Thanks for pointing it out.

I'm completely with you, if the module is not part of it, it will cause pain. That's why a bit further down, I argue that per default, the modules should be used as namespace, which is going to be part of the string to be hashed.

I think there is still a use case for changing the namespace at will. But I admit I have to think it through more to come up with a decent design.

For UniversalTypeId, I assume no namespace sharing, which should be understood as always the default namespace is used. I think this should resolve the problems you're correcly pointing out.

Haha, no I wasn't even aware of it :sweat_smile:

Hi,

I finally have access to a PC again. I decided to address the points raised here in a small update to the article. (Diff can be viewed on Github) Thanks for the valuable input!

Also, I noticed I missed to answer one question.

Yes, there are many implementations of this concept. I believe this also exactly what TypeId was meant to be used for, so I claim no innovation for anything in section 1. It is only there to explain the concept to readers who are not familiar with this already.

I called it untapped potential because I think we can apply this more widely. Such as library-based dynamic object+method dispatch, as discussed in section 2. You could build that on top of typemap but as far as I know, nobody has done it, yet, hence untapped potential.
With section 3, I show the limits of TypeId and I discuss options how they could be lifted, which would eventually lead to more potential use cases.

I hope that makes sense. Next post, I'll try to keep it shorter, which is always easier to follow. :slight_smile:

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.