> Why would you do that?
a getter?
> This is an actual _pattern_? Yikes^2.
wat.
a getter?
> This is an actual _pattern_? Yikes^2.
wat.
Getters return values. This returns a pointer. So it's an accessor. With unchecked semantics. It's bizzare to me that anyone would use this technique. It's all downside with no upside.
> wat.
I'm expressing surprise that anyone would do this. I'm sure you were capable of understanding that.
When I use getter, I want to see the value of a field. I don't want an owned copy of said value, I just want to look at it, so returning reference makes _a lot more_ sense than returning a copy. In example it uses `i32`, but that's just for readability.
> I'm expressing surprise that anyone would do this. I'm sure you were capable of understanding that.
Yes, and I'm expressing surprised that you think it's bad. I'm not even sure what is bad? Lifetime elision that is well documented and works in a non-ambiguous manner? Using references instead of values? Do we need to memcpy overything now to please you?
You can look at it with an owned copy. What is the issue? Is premature optimization the default mode in writing Rust? You don't see the issues with this?
> I'm expressing surprised that you think it's bad
You're surprised that someone simply has a different opinion? Your reaction failed to convey that.
uhm, common sense isn't a premature optimization. Avoiding a needless copy is the default mode in writting rust and any other language.
This isn't exactly a pointer: Rust distinguishes between read-only and mutable ("exclusive") references.
This returns a read-only reference, so it's very much like a getter: you cannot use it to modify the thing it points to.
It's just that it does it without a copy, which matters for performance in some cases.