Naming guidelines for extension-Traits?

[epage]

Should we have a naming guideline to avoid ambiguity from two crates providing extensions to the same type?

Background:

Extension traits, like PathExt are a mechanism to provide additional functionality to an existing type.

Options for using a trait

• use the <Type>Ext, allowing direct access to its func like val.func()
• Directly reference the trait: <Type>Ext::func(val) rather than val.func()

If two crates provide a <Type>Ext for the same type, then you're only option is to go with the uglier route after running into this.

I ran into this when experimenting with error-chain and failure which both provide ResultExt. In this case, the only reason I ran into it was comparing the libraries. I don't expect the ResultExts to be mixed in code, so I didn't create an issue for failure. I assume there are other reasons to run into this though.

[Kixunil]

Name collisions can also be solved by use FooExt as FooExt2 but I do agree that <Type>Ext naming is sketchy.
Perhaps suggest that docs could contain "extension trait" somewhere if the intent is to express the purpose.

[KodrAus]

I think if the goal of the trait is just to augment standard types with additional functionality then the <Type>Ext approach is fine. All you need is to bring that trait in scope so if you have to alias it then so be it.

If a library is providing a trait that it expects others to implement or use in generic bounds then it's probably worth coming up with a better name than <Type>Ext which is pretty non-descriptive.

[Kixunil]

I wonder if there's any downside in allowing people to come up with descriptive names regardless of the purpose while also considering <Type>Ext being fine.