Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storing unboxed trait objects in Rust

guiand.xyz

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Storing unboxed trait objects in Rust

#11

Post by comex »

majewsky wrote: post #9
MHordecki wrote: post #8

Earlier quoted context omitted.

Note that it's quite possible for a trait to have infinitely many implementations in any given program. For example, Debug is implemented by u64, Box , Box >, ..., and so on. While these happen to have the same size, it's not hard to imagine a situation where this is not the case.

Your situation is already sufficiently impossible because it shows that for a given trait, the set of implementors is often (countably) infinite.

However, the number of implementors actually instantiated in any given program is necessarily finite. You could write a program that would make it infinite, e.g.

    trait Foo { fn foo(); }

    impl Foo for T {
        fn foo() {
             as Foo>::foo();
        }
    }
...but the compiler can't compile it: since Rust implements generics solely through monomorphization, that would require generating an infinitely large binary :)

Re: Storing unboxed trait objects in Rust

#12

Post by cornstalks »

saagarjha wrote: post #6
cornstalks wrote: post #3

This post reminds me of a problem I've hit with my Objective-Rust project[1] (Rust code that's interoperable with Objective-C), to which I haven't found a good solution. The closest analog to Objective-C's @protocols in Rust are traits. I would love to be able to transliterate the following Objective-C: @protocol SomeProtocol // methods @end void demo() { // Just a demo of how to use SomeProtocol with a var: id varia…

I don't know enough Rust to completely understand what you are talking about with object safety, but this is a very interesting project. How do you plan to handle Objective-C's runtime features? Even if you don't plan to implement advanced features like objc_allocateClassPair, one thing you will have to deal with rather quickly is informal protocols and optional methods, which are resolved at runtime.

Runtime modifications to the Objective-C runtime (e.g., objc_allocateClassPair) will have to go through libobjc, just like they do in Objective-C. I could provide friendlier interfaces to libobjc, but I don't plan to.

objrs already supports optional methods (for externally-defined protocols), though using them is the same as in Objective-C (you still have to call respondsToSelector: first). I've thought about adding an additional API that simplifies this a bit (i.e., a method that returns an Option, where it's None if the class doesn't respond to the method, or Some(fn) if it does (where fn is a closure you can use to invoke the function)).

Re: Storing unboxed trait objects in Rust

#13

Post by cornstalks »

comex wrote: post #10
cornstalks wrote: post #3

This post reminds me of a problem I've hit with my Objective-Rust project[1] (Rust code that's interoperable with Objective-C), to which I haven't found a good solution. The closest analog to Objective-C's @protocols in Rust are traits. I would love to be able to transliterate the following Objective-C: @protocol SomeProtocol // methods @end void demo() { // Just a demo of how to use SomeProtocol with a var: id varia…

Ideally you want `Id` to actually be parameterized on traits, not trait object types that happen to have the same syntax (now deprecated) as their corresponding traits. Of course, that's not currently possible. But you may be interested in this repo for planning an RFC to eventually add such functionality: https://github.com/Centril/rfc-trait-parametric-polymorphism... After being created 8 months ago, it's sort of i…

Oh neat! I hadn't seen that one, but it's literally item #20 on my Rust wishlist. I'll have to file an issue to give some motivating examples. Thank you for pointing it out to me!

Re: Storing unboxed trait objects in Rust

#14

Post by shmerl »

> Rust, not being an object-oriented language, doesn't quite do inheritence like the others. In C++ or Java, subclasses extend superclasses. In Rust, structs implement traits.

I wouldn't say that Rust isn't object oriented. It just takes a different approach to some things. Inheritance isn't really a strictly required feature of the object oriented code design. Many for instance pointed out, that composition is preferable:

https://en.wikipedia.org/wiki/Composition_over_inheritance

Re: Storing unboxed trait objects in Rust

#15

Post by millstone »

shmerl wrote: post #14

> Rust, not being an object-oriented language, doesn't quite do inheritence like the others. In C++ or Java, subclasses extend superclasses. In Rust, structs implement traits. I wouldn't say that Rust isn't object oriented. It just takes a different approach to some things. Inheritance isn't really a strictly required feature of the object oriented code design. Many for instance pointed out, that composition is prefe…

Rust is clearly not object-oriented. It has very minimal support for late binding, and no support for reflection or dynamic libraries.

This isn't a critique, it's just a statement of fact. No Rust designer will say they set out to build a new object-oriented language.

Re: Storing unboxed trait objects in Rust

#16

Post by giornogiovanna »

millstone wrote: post #15
shmerl wrote: post #14

> Rust, not being an object-oriented language, doesn't quite do inheritence like the others. In C++ or Java, subclasses extend superclasses. In Rust, structs implement traits. I wouldn't say that Rust isn't object oriented. It just takes a different approach to some things. Inheritance isn't really a strictly required feature of the object oriented code design. Many for instance pointed out, that composition is prefe…

Rust is clearly not object-oriented. It has very minimal support for late binding, and no support for reflection or dynamic libraries. This isn't a critique, it's just a statement of fact. No Rust designer will say they set out to build a new object-oriented language.

Late binding is the only one of those features commonly associated with object-orientation, and Rust is just as good as C++ on that front.

Re: Storing unboxed trait objects in Rust

#17

Post by giornogiovanna »

v_lisivka wrote: post #5

IMHO, Rust just should take size of the largest implementation of Animal for `impl Animal`, and viola — we can make them static. No heap is good for embedded.

You can obviously use an `enum` for this, and it's not so clunky that I think Rust should add yet another feature for it.

Re: Storing unboxed trait objects in Rust

#18

Post by shmerl »

millstone wrote: post #15
shmerl wrote: post #14

> Rust, not being an object-oriented language, doesn't quite do inheritence like the others. In C++ or Java, subclasses extend superclasses. In Rust, structs implement traits. I wouldn't say that Rust isn't object oriented. It just takes a different approach to some things. Inheritance isn't really a strictly required feature of the object oriented code design. Many for instance pointed out, that composition is prefe…

Rust is clearly not object-oriented. It has very minimal support for late binding, and no support for reflection or dynamic libraries. This isn't a critique, it's just a statement of fact. No Rust designer will say they set out to build a new object-oriented language.

C++ has no reflection either. Are you saying it's not object oriented?

Rust has late binding (also known as dynamic dispatch). Check trait objects. It's not really any worse than C++ virtual functions which is its form of dynamic dispatch.

See https://doc.rust-lang.org/book/ch17-02-trait-objects.html

And Rust has dynamic linking as well: https://doc.rust-lang.org/reference/linkage.html

So IMHO Rust has enough features to be used in object oriented fashion.

Post reply on HN