Aliasing other things

language design
50

I can see some value in aliasing names. In fact, rust already allow some form of aliasing using the use keyword. And probably we could extend it to new scopes.

struct Color;

// this already works today
use Color as Colour;

trait Hello {
   fn color(&self) -> Color;

  // proposed: allow to use `use` within `trait` and `impl`
  // of course, this would only allow to import item from the trait itself. 
  // (What would it means otherwise?)
   use color as colour;
}

// For enum and struct it is a bit more complicated since one cannot really put a `use`,
// but one  could put them in a impl
struct Foo {
    color: usize,
}
impl Foo {
   use color as colour;
}

The color/colour example might not appear so usefull, but I see some value when one wants to deprecate names.

impl str {
   // new name
   pub fn trim_start(&self) -> &str { /* ... */ }

   // old deprecated name still available
   #[deprecated(since = "1.33.0", reason = "superseded by `trim_start`"]
   pub use trim_left = trim_start;
}

This syntax would allow to rename and keep the deprecate names of trait items or enum variant which may be desirable sometimes.

2 Likes
51

use in an impl block could mean the exact same as use in the parent scope, just scoped to the impl block rather than the parent scope.

This does not prevent being used to alias methods, it just requires marking them pub.

It could also be used for delegation.

52

Deprecating and refactoring stuff is one of the few use cases where I think something like name aliases could be useful.

However, simply renaming stuff is rather limited, often you have logic changes that go with it. Hence why I think properties would be more useful (trait methods not withstanding).

Conversely, for accessibility I don't think this is the right approach at all: it would require every crate author to annotate everything ahead of time, in all the relevant spellings, and yet avoid name clashes. This seems hardly feasible.

1 Like
53

I proposed properties before, but was ultimately convinced that they wouldn't be very useful in Rust, because struct fields can't be replaced with properties in a backwards-compatible way.

All proposals in this thread are flawed, since they doesn't work across crates. A better syntax would be

use some_crate::Foo::{self, self.color as colour};

let foo: Foo = ..;
assert_eq!(foo.color, foo.colour);

Note that self.color can be a field or a method. If a field and a method both have the name color, both are renamed.

This would even enable us to convert a tuple struct to a struct with named fields:

// this works today:
struct Foo(u8, u8, u8);
let _ = Foo { 0: 255, 1: 0, 2: 0 };

// if we could rename fields, we could write this:
use Foo.{0 as red, 1 as green, 2 as blue};
let _ = Foo { red: 255, green: 0, blue: 0 };

However, I'm still not convinced that this actually needed. Language features need a strong motivation; for example, type aliases are used to make type declarations smaller and less generic, and imported items can be renamed mainly to prevent name clashes when importing multiple items of the same name.

6 Likes
54

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.