This is a false premise.

1. Users do not have IntelliSense in the console (they have TabExpansion, which is not the same, at all).
2. Users are not "typically satisfied" without aliases.

Users use aliases all the time. Particularly in the console, but also in scripts and script modules -- as can be easily demonstrated by examination of source code repositories.

Additionally, users complain when you remove aliases. In fact, that's why this RFC is being written: because each time the PowerShell team makes changes to aliases, the users feel pain and complain -- this, in and of itself, demonstrates users aren't satisfied with typing out the full names of commands.

Just want to echo this. Alias use is huge in the console, and even in writing custom scripts. When teaching new users, unfamiliar with PowerShell, the using aliases can help simplify adoption.

We do not have it today, but I think IntelliSense might be a good solution. PSReadLine 2.0 gets us very close! If it can be made to work as you type instead having to press CTRL + SPACE, then it could be used.

With IntelliSense driven, you could have 3 choices when typing an alias in this order:

• Executable when alias matches an executable
• Fully Resolved Name
• Alias

Include the details on which one it resolves to would ensure the right one is picked.

I think that what we do now in TabExpansion is far too slow to be used as IntelliSense.

Sometimes so is ISE and VS Code.... It is an idea. Of course it isn't useable now, but with development focus, it could be quite useful. In fact, I use ISE as the "terminal" because of Intellisense.

IntelliSense can actually be counter productive in some situations, consider the Azure modules.

Just want to echo this. Alias use is huge in the console, and even in writing custom scripts. When teaching new users, unfamiliar with PowerShell, the using aliases can help simplify adoption.

I just wanted to disagree with this. When helping junior staff learn PowerShell or introducing it to completely new learners, using aliases have always been a source of confusion.
% and ? have no logical or intuitive connections to Where-Object or ForEach-Object.
FT/GM/FL might be easier to type, but Get-Member encourages new learners to actually internalise when the command does and is for.

Users are not "typically satisfied" without aliases.

While users might not be typically "satisfied" without aliases, it is hugely annoying that you never know when an alias from one module will block the importing of another module, unless you first run a command to remove all modules. Something which has easily cost me more time than time I have saved writing GCI instead of Get-C{tab}

the dis/enabling of aliases would be better handled in a profile

And so by not having any aliases in PowerShell at all, but maybe include a profile.ps1 file that includes a couple of aliases, you can show people how to create their own if needed.

I believe PowerShell is primarily about interactive sessions. The phrasing in this section makes it sound as though you think interactive sessions are a secondary mode that only a few people use...

What are you talking about here? What DSL? How would that supplement aliases?

Confused why we would expect users to learn another DSL. This sounds excessively complex.

Please don't ask me to use ML in my interactive console.
Users don't even want their PowerShell command usage to be exposed to Microsoft, never mind the actual command-lines as they type.

ML raises privacy, performance and security concerns for me.

What DSL?

I'm not here to correct grammar, in general, but this sentence confused me. I believe this sentence means:

However, despite their best intentions, developers sometimes cause conflicts in their module's aliases.

Statements like this keep getting repeated -- but they are not relevant.

The fear of aliases being changed is irrelevant except when PowerShell changes it's defaults.

In fact, aliases are no more likely to be changed than the commands that they point to --- it is even possible to register a function with a name that clobbers the so-called "fully qualified" command name. There are, in fact, several modules in the gallery which replace or "clobber" built-in commands (including commands which have built-in aliases) -- but I don't know of any which alter any of the built-in aliases.

To which I'm dealing with right now, PowerCLI and PSCX conflict with built-in cmdlets and ones I wrote. There is no easy-clean way to stop that because of Autoloading of Modules. I see no difference with Aliases in this context.

The reliability of the environment from importing new modules or scripts is a separate issue and RFC.

To which I'm dealing with right now, PowerCLI and PSCX conflict with built-in cmdlets and ones I wrote. There is no easy-clean way to stop that because of Autoloading of Modules. I see no difference with Aliases in this context.

The reliability of the environment from importing new modules or scripts is a separate issue and RFC.

This is pretty much the issue that is currently making me blow a gasket.
Hyper-V, Power-CLI and VirtualMachineManager all use some overlapping aliases, which either cause imports to fail, or commands to not run as expected. Hence why I am having to remove all aliases.

This would probably be the single biggest breaking change ever proposed.

This surprised me as well. I assume this means the inverse (to preserve back-compat all aliases are loaded by default). Separate to this is perhaps an ignorant (but important to me) question: Does my powershell.config live next to my profile.ps1? I would like a way from my user session to ensure no PowerShell "builtin" aliases are included in my interactive session without scrubbing them by hand in my profile, but I don't want to change machine state and I don't want to have to do this manually on every machine I spin up (I auto-sync profile.ps1 today, and I want a mechanism that lets me auto-sync these settings alongside)

powershell.config(.json) lives in the install folder of PowerShell Core

As far as I know, currently it has to be re-edited every couple months when you deploy the latest PowerShell. That's one of the reasons I don't want this sort of thing in there 😉

Agree this is a massive breaking change.

I am also concerned with the suggestion of powershell.config(.json) as it is a per install not a per-user setting. Edit: I see you suggest we could load them manually during a session.

Some users might want different alias options if this change was to go forward, it would also require more deployment work for each new PS Core release.

Of course, @kjacobsen -- the overall intention is to make it so that the only aliases present are the ones the user wants. They can choose to use one of the default sets, or create their own sets. If the choice is managed in your profile --or a unified config location-- there should be no repeating deployment work, you'd just have a one-time need to create or modify a profile, right?

I would like to propose another point to the "alias policy" and that would be to prevent the creation of Functions or Aliases which include slashes in the name. That is:

1. PowerShell prevent modules and users from clobbering "fully qualified" command names.

Should we add * select -> Select-Object ?

I believe that these are just examples -- but perhaps we should have a discussion about them. If we're going to create a list of "standard" aliases that will always be there, that list becomes almost sacrosanct, and none of these "standard" aliases should ever be removed. Right?

In any case, this particular list is problematic. I agree that the aliases for the *-Object commands are some of the most used, but you would need to include not just select but also sort, tee, and group, as well as compare and measure ...

However, where and sort are probably already on the chopping block (as-in, should have been removed already, based on my understanding of the new rules) because they clobber built-in command-line executables in Windows. If those two need to be removed to an optional set, then I don't see any reason to include any of these outside of an optional set.

Given that, I think probably there are no standard aliases.

Should be:
These aliases were removed from PowerShell Core.

Should highlight that this also disrupts some modules that would normally work in PS Core.

It also disrupts the operation of custom scripts and modules that use these aliases.

We are assuming that users are in a position to customize their environments. Sometimes you don't get the chance due to the way stuff is deployed or corporate policies.

I certainly wouldn't say that aliases have limited functionality. They provide a significant productivity boost. Consider the common technical of the alias g for git. That saves a considerable amount of time in the long run.