Better wrapper structs

[coolCucumber-cat]

So there isn't inheritance in Rust but you can easily make wrapper structs and implement methods on that. Since this is quite common, there could be a way to avoid needing to always access the extra fields. It's common to use a tuple with one field but normal structs are common too, like String which is a wrapper over a Vec<u8>. I'm not sure how to do this or if it's even needed. If you have your own ideas or you can improve my ideas, feel free to comment.

So my main idea is just a sugar syntax over a tuple with a single field. It would be like the inner type, but with the extra methods from the outer struct. I have 2 ideas how to do this syntax for this idea, using measurements as wrappers over numbers:

1. some keyword (wrapper as a placeholder):

wrapper struct Millimeter(u32);

let mm = Millimeter(21);

2. a struct but without fields, only a type:

struct Millimeter u32;

let mm = Millimeter 24;

Which can then be used like this:

impl Millimeter {
	fn to_meter(self) {
		Meter(self / 1000)
	}
}

Millimeter is treated exactly like a u32 but with those extra methods from Millimeter too. So u32 works a little bit like a trait that Millimeter implements and you can pass it to anything that expects a u32 and can also be coerced to a u32:

let mm = ...;
expects_u32(mm);
let num: u32 = mm;

If you don't understand how something might work, I can give more specific examples or you can send me an example and I'll tell you how it would. Or you can send me examples how you think it should work or give an example that demonstrates why it won't work. There could be many situtations where it is very ambiguous.

Is it even worth the effort? I'm trying to learn more about Rust. Understanding what the boundaries are, so explanations why this won't work are appreciated 😁.

[Johan-Mi]

Do you really want a newtype wrapper without any restrictions on accessing the underlying type? For example, should it be valid to add Millimeter to u32 or raise a number to the power of millimeters?

[coolCucumber-cat]

Do you really want a newtype wrapper without any restrictions on accessing the underlying type? For example, should it be valid to add Millimeter to u32 or raise a number to the power of millimeters?

That's a very good question I'm not sure about. There are two possible solutions:

1. yes: Millimeter would be treated as a u32. Those two operations would work as if it were a u32.
2. no: you would have a conversion with as u32.

But I think that raises an even better question: should it be possible to add a u32 to Millimeter and raise a Millimeter to the power of a u32?

1. yes: Millimeter would be treated as a u32. Those two operations would work as if it were a u32.
2. no: there should be no conversion to be more specific and Self refers to Millimeter and u32 cannot be turned into Millimeter.

So this boils down to two questions:

1. should the outer type be allowed to be coerced to the inner type
2. vice versa, should the inner type be allowed to be coerced to the outer type

[coolCucumber-cat]

@kennytm Do you have any extra feedback? I need more info than just a confused emoji. If there is something that you are confused about, I can answer it.

[kennytm]

@coolCucumber-cat yes have you researched for existing proposals before? this is most likely a duplicate of #949 and #2242

[coolCucumber-cat]

@shepmaster Can I get more feedback than a reaction? I want to hear your reasoning and maybe I can improve or close this issue

[senekor]

@coolCucumber-cat stop tagging individuals like that, it's rude. Clicking on a reaction button doesn't express willingness to participate in the discussion. And it doesn't give you permission to cause a distraction for someone simply demanding their time and attention.

maybe I can improve or close this issue

You have been made aware your issue is a duplicate. Start by addressing the conclusions of the previous work.

[coolCucumber-cat]

@senekor Sorry if I don't know all the rules. Is this GitHub specific because I've never heard of that before. I wasn't demanding them to, I was asking if they could just help me out, maybe they could improve. They don't have to respond if they don't want to. Us tagging eachother could also be considered a distraction, it seems like a very blurry line to draw.

About the duplicate, I forgot to address it, it wasn't intentional, but I don't think it is a duplicate because it's vaguely the same concept, but implemented in a very different way, as far as I understand. There aren't really any similarities and those other issues don't really even concretely talk about how it should be implemented.