Looks like a huge oversight

Guys, just voicing my opinion based on latest experience using composition of 3rdParties structs in order to customize behavior.
Rust simply is not ready to do it with ease. Something that in lets say C++ requires literally two words, in Rust becomes a nightmare of forwarding every required method. What's even worse, there are some scenarios like non associated functions that there is simply no way to easily just forward.
I really don't understand why something like that was overlooked specially taking the fact into consideration that Rust by design knew it will prefer composition over inheritance and yet didn't provide convenient syntax to actually use it.

struct MyStruct
inner: ThirdPartyStructWithLotsOfFunctions,
impl MyStruct
/*implement own or modified functionality
//forward the rest:
use inner;//Is this something that was thought of and discarded for some valid reasons?
impl ATrait for MyStruct
use inner;

The two words you refer to are the public Parent in class Child: public Parent { ... } and how inheritance is implemented in C++.

C++ doesn't have a way to defer all methods to a field, either.

Adding something as a field and having methods deferred to it isn't what most people mean when they talk about composition, it's actually closer to a form of prototypal inheritance (as in JavaScript) or Go's struct embedding.

If you were doing composition, you might expose the inner as a public field and let consumers interact with it directly.


C++ doesn't have to do it because of the inheritance.That's my point.
It is Rust that doesn't have convenient way to extend functionality not C++.

This is the third time in the past day that you have created a new topic for the exact same thing. Please use the threads that you have already created, rather than clogging things up for others. It also helps keep discussion centralized.


This is similar but different topic.

Please explain how it is different. Upon first glance, they are nearly identical.

1 Like

In the other topic I was asking how to do it. Here I am asking why isn't done the way I've shown example how natural it could be.

That is the kind of thing that should be done in the original topic. Even setting that aside, your two posts from within the past hour do not have that distinction.

It's fine for topics to drift slightly from the original. That's the nature of a discussion.


And I didn't want to obscure the other discussion where is simply created to get an answer to solve my problems not discuss Rust's problems.

If your goal is to try and change something in the language, I shall direct you to internals.rust-lang.org. The topic is delegation, which has been thorough discussed previously. I highly suggest you look into the history of these various discussions; you were pointed to one in a previous thread.

But as to my original point — this should have been one thread, not three. I stand by that assertion as a long-time and frequent user of this forum.


It sounds like the OP has a particular way they want to do something based on their experience in other languages (note the frequent use of the word "extend", implying inheritance) and have been frustrated when Rust prefers to do things differently.

From the outside this looks like a classic X-Y problem. @piter76, maybe you can state what you are actually trying to achieve instead of saying how you would inherit from the type the override one method in C++.

To answer the thread's original question, there isn't really an oversight here.

There are other ways of achieving what you are trying to do, and in an ergonomic way, but you are encountering a lot of friction by trying to reuse an OO technique in a non-OO language. It's like how writing functional code is extremely awkward and frustrating in Java.


Extension traits are a very good solution for that and someone already posted an example of it:


I'm aware of what OP is trying to do. Check their profile for what I'm referring to. I've no issue with a single thread being created for this purpose.

The methods I need to implement are not methods in traits but within structs. Can I do that using extension traits?

Sure. What I'm trying to achieve is this:
I need to modify some functionality of 3rdParty struct called Dialog. Some of the functionality is inside that struct some of the functionality is inside traits. Some of the functionality are non-associated functions that return Self.

struct MyStruct
inner: DialogWithLotsOfFuncionsAndTraits

I didn't really understand whay you meant but you can't impl directly on an external struct. But you can implement your traits on whatever you want.

How would I do let's say this:

struct ThirdPartyDialog
fn some_functionality_I_need_to_use()-Self;

I can't currently tinker with the code but why you want to override a function name? Since you say "modify" I think you want to change a method of the inner type.

The code snippet you posted just looks like a constructor... If you are just trying to construct the object in a different way, can't you create a free function?

fn dialog_with_custom_property_values() -> ThirdPartyDialog {