4 ms·
> If you really need a 16-tuple (unlikely, but...) you could copy paste the code to make one with the same features. This isn't compiler support, so you could j
by estebank 5y ago
> If you really need a 16-tuple (unlikely, but...) you could copy paste the code to make one with the same features. This isn't compiler support, so you could just do it yourself.
There's one wrinkle in that strategy in that you might run afoul of the orphan rule[1][2] where you can't write:
impl ForeignTrait for ForeignType {}
because if we did it would be brittle and changes to an external crate could make your unchanged crate stop compiling. So you're restricted to either implementing your own trait or any trait on a type you declared. To "get around this" you can use the new-type pattern[2]:
struct MyArray<T>([T; 33]);
impl ForeignTrait for ForeignType {}
[1]: https://github.com/Ixrec/rust-orphan-rules https://github.com/Ixrec/rust-orphan-rules
[2]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1c59e381266cb2699d7f32e52a4538da https://play.rust-lang.org/?version=stable&mode=debug&editio...
- tialaramex 5y agoMy error. Good point about the orphan rule. Because I was writing about Tuples what I was talking about is actually impossible in your own code I think, because tuples are inherently foreign. Even though the code in std looks tame, you are forbidden from doing this elsewhere. Even for a hypothetical local type MyType you are forbidden from attempting: impl ForeignTrait for (MyType,u8) The compiler will conclude that ForeignTrait is foreign, of course which is what we expected, but (MyType,u8) is also foreign even though MyType is local and so the orphan rule forbids this definition. Shame. It doesn't make any sense to sidestep with new type because if you didn't want a tuple you could already define whatever type you wanted and this isn't an issue anyway, whereas if you do really want a tuple then a new type isn't a substitute.