I was looking at the new vcpkg website, and starting to peruse the code (available here). From the website:

vcpkg is a free C/C++ package manager for acquiring and managing libraries. Choose from over 1500 open source libraries to download and build in a single step or add your own private libraries to simplify your build process. Maintained by the Microsoft C++ team and open source contributors.

https://vcpkg.io

While I don’t do a lot of C++ development, I do like to look through our offerings when they GA. In this case, the first thing it asks you to do in the Getting Started page is run a batch script, which in turn calls a PowerShell script.

Check out this code:

Line 3 is a named parameter called $badParam. This becomes important a little later. Lines 4, 5, 6, and 7 are named parameters. Now, how can we enforce that someone uses those named parameters.

This is where the fun bit begins. Line 11 checks to see if $badParam has been set, which will happen if you call this code thusly “bootstrap.ps1 blah”. It auto-assigns “blah” to $badParam. Now we know no one would willingly assign to $badParam so that means they aren’t using named parameters. We then throw an error on line 19.

It’s a bit of code trickery that can be useful for scripts that you need named parameter enforcement on. In this case, the next few lines actually tell an even more important story.

Three of the four named parameters are no longer being used. But why do they insist on them being named parameters? We can check out the blame view on Github to see why.

In this case, they wanted to normalize the parameters between the Windows/Linux/MacOS scripts, but they still wanted to deprecate usage of them without throwing errors.

You won’t need it for your internal scripts. But if, like vcpkg, you’re publishing them out to the world, it’s a way to gracefully deprecate named parameters.

Til next week!