Remove weak alias terminology

[BoxyUwU]

I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.

It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about weak aliases, when I'm not really sure what the basis for that as the term actually is.

I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)

r? @oli-obk

maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

changes to the core type system

cc @compiler-errors, @lcnr

changes to the core type system

cc @compiler-errors, @lcnr

HIR ty lowering was modified

cc @fmease

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[BoxyUwU]

I tried to just grep for weak anywhere in the compiler/tooling and see if its related to weak aliases or some unrelated usage like the Weak std type, the many places its used for weak aliases in linking, as part of the word tweak, etc. I might have missed some occurances though

[oli-obk]

which do not exist

Right. My assumption was that we would want to differentiate from strong type aliases that other languages have.

The rename seems fine to me tho, I find it unlikely we'll ever have strong type aliases

[BoxyUwU]

That distinction would be meaningful for all of our alias kinds right? Like AliasKind::Projection/Inherent are also not strong type aliases from other languages and are kind of "weak" aliases in some sense. I would imagine that if we were to have a weak/strong distinction it wouldnt be with an AliasKind::Strong but a separate axis that any of our existing aliases could either be weak or strong. Maybe I'm a little off base here though, I'm happy to be wrong here I just want to wind up at a state where I can make whatever naming scheme we have "seem intuitive" to contributors

[oli-obk]

I don't think strong aliases make sense as sth for inherent or associated types. Strong aliases would be more like an adt that has its trait impls inferred from its aliased type. I have not seen any design for that which would work in Rust. I think the newtype pattern is more effective as it gives all the control and none of the issues, albeit requiring manual trait impls.

[lcnr]

using free alias seems clearer to me, so 👍

[oli-obk]

@bors r+

[bors]

📌 Commit bdfeb8f has been approved by oli-obk

It is now in the queue for this repository.