This is a BC break

It's most likely not going to happen, it has been suggested before. I've already made a PR I find better solution:#11957

You can already use thesession.flash_bag service and inject it. Session as a service will most likely disappear as it is right now in symfony 3.0, check#10557

Session as a service will most likely disappear as it is right now in symfony 3.0

This is one more reason to have the method on the interface, because then the only way to cleanly get at it is throughRequest::setSession() andRequest::getSession()

@yguedidi updated the issue summary. Still I'm wondering on the impact of this BC break. Existing third-party session implementations are forced to add a new method, is that the problem?

@znerol Yes it is. Maybe they aren't open sources implementations, but maybe they are in closed sources projects.

This is one more reason to have the method on the interface, because then the only way to cleanly get at it is throughRequest::setSession() andRequest::getSession()

There are no concrete plans, but I doubt this will be added as it is.

I did my share in grepping and pickaxing through the git history. Here is what I found:

The large session refactoring in#2853 introduced theSessionInterface. For some time that interface had a methodgetFlashes() which was removed by commitdad60ef of the pull request. The removal likely happened accidentally because it is clearly visible from the same diff thatSessionHelper used this method to retrieve flash messages. Note thatSessionHelper still happily uses its successorgetFlashBag() in master (without theinstanceof checks shown in the example code of#11957). Other usages are inFrameworkBundle/Controller/Controller.php,WebProfilerBundle/Controller/ProfilerController.php,WebProfilerBundle/EventListener/WebDebugToolbarListener.php,HttpKernel/DataCollector/RequestDataCollector.php.

How likely is it that a third partySessionInterface implementation would even work with Symfony if it would strictly adhere to the interface and leave outgetFlashBag()?

@znerol this was back in 2.1 if I checked correctly. As of 2.3 semver is being followed and BC breaks should be avoided, this is one of those cases.

@iltar I do not argue that a BC break is okay here because it was fine then. I just want to point out that this was broken from the beginning and that it is still inmaster.

Duplicate of#11279#10036#5568.

It's not broken, it's like this by design (I'm talking about getFlashBag not being on SessionInterface, not about client code using SessionInterface as if it was a Session). See@Drak's reasoning for rejecting this in the past here:#5568 (comment)

getFlashBag() is just a shortcut method provided by Symfony's implementation of SessionInterface. We don't want to force all the implementations to support flash bags. You can use it Session as a typehint, if you really want to rely on this specific implementation. Otherwise, usegetBag(), which belongs to the interface.

The SessionInterface is technically not tagged with an@api (its methods are), but we try to limit BC breaks as much as possilble.

How isFrameworkBundle/Controller/Controller.php not broken when it operates onSessionInterface and still wants to usegetFlashBag()?

@znerol that's why you can inject thesession.flash_bag service. I know it's broken and I'd like to see it fixed. But at this moment, theSessionInterface doesn't and shouldn't know about framework specific implementation.

@znerol FrameworkBundle/Controller/Controller.php does not operate on SessionInterface but on the session service which is configured to behttps://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Resources/config/session.xml#L8

@Tobion I mentioned other examples as well, e.g.SessionHelper (which retrieves the session from the request and the request is clearly type hinted againstSessionInterface). Also as an exercise for the interested reader: Try to operate any Symfony application with aSession implementation lackinggetFlashBag(). An easy way to do this is simply to remove the method. I guess that in 99% of all cases your application will explode instantly.

@znerol I agree with you but your example was not ideal. There are also several other design problems I already reported:#9233

Closing for the reasons explained by@Tobion.#9233 has all the information we need to move forward. It's now up to someone to think about how to tackle this issue for the next Symfony version.