Adam Harvey wrote: > What about just adding another function: setlocale_global(), or similar?
Do you mean setlocale would become the thread safe one, and setlocale_global() would be the current behaviour? If so, that would be a BC break for the small number of people who are deliberately using setlocale globally. We could do that at a major version I guess. I think the ini setting is still better - it allows people to use code that was written assuming that setlocale was safe to use, rather than forcing them to change it. It might be best to introduce both setlocale_ts() and setlocale_global(), so that users could call either explicitly, and have the ini setting control which one setlocale() points to. If we did that we could also then plan to eventually deprecate both the ini setting and the plain setlocale without _ts/_global. Ryan Pallas wrote: > I like the idea of an INI actually, but I would make it default to the > current behaviour and user education so those who need TS know to change it. The problem with that is that for people who aren't aware of the setting, they wouldn't know that they need to change the setting. Instead they just want their code to work properly 'out of the box'. For the vast majority of people calling the thread safe version of setlocale would be what they problem want it to do, and so PHP should default to the right thing for the majority of people. Of course there is a separate argument about changing the behaviour at major/minor version, and if this was introduced then having to `thread_safe_setlocale=off` for 7.1 and `thread_safe_setlocale=on` for 8 could be correct. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
