On Wed, Sep 21, 2016 at 10:13 AM, Nicolas Grekas <nicolas.gre...@gmail.com>

> >
> > See https://github.com/php/php-src/pull/2136
> >>
> >
> > I don't like this.
> >
> I understand, really. I do have to deal with BC on Symfony side also and
> it's a really hard constraint. Yet, we stick to it as much as possible, in
> order to not add pain to others.
> Sometime, we have to be pragmatic and accept solutions that are not "pure",
> for the shake of our BC promise.
> PHP internals has such a BC policy, it should really stick to it. It's not
> always fun, for sure, but the pain for others it strong. It's not only
> me&Ocramius, nor Symfony&Zend: everybody not following internals to adapt
> to latest BC breaks will be hit, potentially. This is bad for the
> reputation of PHP. It makes the PHP platform unstable as far as confidence
> is concerned.
> In this case, we should find a technical solution that preserves BC. Being
> this patch or unconditionally returning the type name with nullable info is
> fine, you'll decide what's best.
> But please don't consider BC as something that one can bypass when it gets
> annoying.
> Thanks from me and from many others for considering :)

I'm not so sure its a BC though. Technically nullable types don't exist in
7.0 and as such would be impossible to return said question mark. Its only
adding support for a new feature, not changing how an existing feature
works IMO. If nullable types had been in 7.0 its highly probably, that
__toString would have returned the leading question mark back then.

> Nicolas

Reply via email to