php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #75609 idn_to_utf8() default of INTL_IDNA_VARIANT_2003 gives deprecation warning
Submitted: 2017-12-01 12:26 UTC Modified: 2017-12-01 13:43 UTC
From: hanno at hboeck dot de Assigned:
Status: Not a bug Package: I18N and L10N related
PHP Version: 7.2.0 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hanno at hboeck dot de
New email:
PHP Version: OS:

 

 [2017-12-01 12:26 UTC] hanno at hboeck dot de 
Description:
------------
The variant parameter of idn_to_utf8() defaults to INTL_IDNA_VARIANT_2003. This gives a deprecation warning in PHP 7.2. Example:

php7.2 -ddisplay_errors=on -r 'error_reporting(E_DEPRECATED);idn_to_utf8("x");'

Deprecated: idn_to_utf8(): INTL_IDNA_VARIANT_2003 is deprecated in Command line code on line 1

If INTL_IDNA_VARIANT_2003 is considered deprecated it shouldn't be the default.

Test script:
---------------
error_reporting(E_DEPRECATED);
idn_to_utf8("x");

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-12-01 12:34 UTC] kelunik@php.net
-Status: Open +Status: Not a bug
 [2017-12-01 12:34 UTC] kelunik@php.net 
This is not a bug, but intended, see https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003

This makes it explicit for users of the old variant that the behavior of their code will change in a future version.
 [2017-12-01 13:43 UTC] hanno at hboeck dot de 
Sorry, but that seems like a terribly illogical strategy.

The majority of users of that function will want to use "the default", whatever that is at a certain point in time.

With that plan of *first* introducing a deprecation warning for the default and only two major versions later changing the default you get this situation:
* Applications that use the function in its default way will get a deprecation warning.
* They will eventually explicitly set the variant to avoid the warning.
* Some years later they can remove that again when PHP 7.4 is the default.
* Many of course won't, so should there be any other default in the future the confusion starts again.

How does that make any sense?
The sensible approach would be to change the default and introduce the warning at the same time.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed May 14 13:01:27 2025 UTC