Big 👍 for supporting--, however ...

To keep BC, I did this by adding a param to hasParameterOption/getParameterOption instead of doing it by default. This creates another BC issue though in that it changes the InputInterface. I don't think that's a major concern but it's worth mentioning.

Following thebc promise, you are allowed to do this since theInputInterface isn't tagged as public API, but you have to follow: "Should be avoided. When done, this change must be documented in the UPGRADE file."

However, it seems more like a bug that theInputInterface is not tagged as public API, since ,for instance,OutputInterface is. In case this is true (@fabpot?), you are no longer allowed to do this.

The other only minor BC change is if you do getParameterOption() of a flag option i.e. --foo without a value. Before it was returning null in ArgvInput and true in ArrayInput. I normalized this to true for both since I think that makes more sense, but strictly speaking while it improves interface interchangeability, it's a BC break.

SinceArgvInput is part of the public API, you are not allowed to change the return type following the BC promise. Also, changingnull totrue means every statement using it will fail (sincenull is a falsey value andtrue is not).

@wouterj regarding the interface. If we can't change it, we can just skip those changes on the interface. Since the new param is optional implementors can add that to the interface AFAIK without breaking anything.

As for ArgvInput.. I can make ArrayInput return null if that's preferable. I don't really mind either way, but anyway it's very unlikely anyone called getParameterOption on an option that doesn't take a value, that'd be kinda useless since hasParameterOption tells you if it's there or not already. Not sure how strictly we want to adhere to the book. By the book isn't my specialty so I'll defer to others :)

What's the current state of this?

I am not sure. I think it was ready but sure should be reviewed. /cc @symfony/deciders

I think this is a good idea and since we need to change the interface (there is no other way to solve this, is there?) it would be a good fit for 3.0.

@Seldaek Is it much work to rebase this onmaster? Would be interesting to if tests still pass.

Rebased.. It can apply on 2.8 or master.

Something seems to be broken (tests in the FrameworkBundle report not existing arguments).

OK build is fixed, travis anyway, appveyor seems unrelated.

Thank you@Seldaek.