style guide: recommend against frequent tuple indexing

[nrc]

I would like the style guide to suggest avoiding frequent tuple indexing. Something along the lines of, "if you are frequently using tuple indexing, consider changing to use a tuple-struct or struct in order to be clear about the nature of fields".

My motivation is that foo.3 gives no indication about the 4th field at all. Whereas foo.position tells you a lot more about the field. Tuple indexing should only be used where the tuple is mostly destructured and there are exceptional cases of field access. If the common access pattern is field access, then a structure with named fields is more appropriate.

cc @aturon

[seanmonstar]

I find myself using self.0 with newtypes.

On Tue, Jan 13, 2015, 12:10 PM Nick Cameron notifications@github.com wrote:

I would like the style guide to suggest avoiding frequent tuple indexing. Something along the lines of, "if you are frequently using tuple indexing, consider changing to use a tuple-struct or struct in order to be clear about the nature of fields".

My motivation is that foo.3 gives no indication about the 4th field at all. Whereas foo.position tells you a lot more about the field. Tuple indexing should only be used where the tuple is mostly destructured and there are exceptional cases of field access. If the common access pattern is field access, then a structure with named fields is more appropriate.

cc @aturon https://github.com/aturon

— Reply to this email directly or view it on GitHub https://github.com/rust-lang/rfcs/issues/581.

[nrc]

@seanmonstar I can't decide if this is a pattern or anti-pattern. I find myself going for anti-pattern - it breaks the new type illusion and makes it look like a regular one item tuple to users of the code. Then again, I think new types are an anti-pattern and perhaps this just makes them more usable?

[ghost]

I'd say anti-pattern too but I also agree that newtypes/wrapper structs are an anti-pattern. Unfortunately, as long as coherence/global uniqueness is a thing in Rust, wrapper structs need to be convenient to use. Coming from Haskell, I'd definitely say that self.0 is better than unFoo for newtype Foo a = Foo { unFoo :: a }.

[seanmonstar]

Tho, I don't mean people should be indexing my tuple structs. I provide a clean API externally. But to make that API, I use tuple indexing instead of de structuring.

I believe newtypes are excellent, and wouldn't call them an anti-pattern myself. It's a way to enforce more constraints on a type, without reinventing the underlying type.

[ghost]

I believe newtypes are excellent, and wouldn't call them an anti-pattern myself. It's a way to enforce more constraints on a type, without reinventing the underlying type.

They are certainly useful in context.

I would consider them an anti-pattern though because this is a role that should really be served by abstraction facilities of a proper module system (in the sense of ML modules). From a language perspective, newtypes/wrapper structs lead to a number of both practical and theoretical problems (e.g., GHC's generalized newtype deriving saga). In Rust, it may be worse due to notion of ownership.