Re: [PHP-DEV] Re: hash_hkdf() signature and return value

[Joe Watkins]

This proposal was rejected.

6 months has not passed since it was rejected.

There will be no vote on these proposals in the near future.

Please stop.

Joe

On Tue, Sep 12, 2017 at 3:52 AM, Yasuo Ohgaki  wrote:

> Hi all,
>
> hash_hkdf() discussion was mess, but it came to conclusion finally a while
> ago.
> Apparently, there are confused readers still. I discovered it in other
> thread.
> I would like to make it clear again what's wrong in the discussion.
> If you think I was wrong about HKDF, you should read this.
>
>
> Nikita and Adnrey's Opinion:
>  1. Keys("IKM") must be strong always
>  (with very limited exception? Usage example is not disclosed)
>  2. From 1, "Salt" is pure optional parameter
>  3. HKDF is designed for specific purpose
>  (crypto keys only? I suppose)
>
> Therefore, "Salt" is the last optional parameter and hash_hkdf() returns
> BINARY.
>
>
> I assume Andrey realized his misunderstanding finally and would not repeat
> this ridiculous discussion. Andrey, you should realize when you couldn't
> show
> us any valid usage example. However, I appreciate discussion because I
> couldn't
> find out where you misunderstood exactly  and why you insisted above
> without
> discussion.
>
> Anyway, their statements make none of sense with HKDF specifications.
> It is easy to accuse "You are wrong" or "You don't understand" regardless
> of
> validity. It requires a lot of work to make it clear what's really
> correct/incorrect.
> Those who are still do not understand what the HKDF RFC is about,  please
> read carefully what  the RFC states.
>
>
>
> What HKDF RFC says:
>
> The algorithm: https://tools.ietf.org/html/rfc5869#section-2.2
> 
> HKDF-Extract(salt, IKM) -> PRK
> PRK = HMAC-Hash(salt, IKM)
> 
> From this algorithm alone, HKDF is clearly expecting weak keys("IKM").
> i.e. Remember how hash_hmac() works.
>
>
> About "Salt": https://tools.ietf.org/html/rfc5869#section-3.1
> 
>HKDF is defined to operate with and without random salt.  This is
>done to accommodate applications where a salt value is not available.
>We stress, however, that the use of salt adds significantly to the
>strength of HKDF, ensuring independence between different uses of the
>hash function, supporting "source-independent" extraction, and
>strengthening the analytical results that back the HKDF design.
> 
> It is clear that salt is made optional only for apps that cannot use salt.
> It is clear that HKDF recommends "Salt" regardless of key("IKM") strength.
> "Salt" is required for  "source-independent" extraction. i.e. Make IKM
> entropy/strength irrelevant and derived key stronger.
>
>
> Omitting "Salt": https://tools.ietf.org/html/rfc5869#section-3.3
> 
>In some applications, the input key material IKM may already be
>present as a cryptographically strong key.  In this case, one can skip
> the
>extract part and use IKM directly to key HMAC in the expand step.
> 
> It says "Salt" may be omitted __only when__ keys("IKM") are strong already.
> In other words, "Salt" is mandatory for not cryptographically strong
> keys("IKM").
>
> e.g. $rsa256key = hash_hkdf("sha256", $rsa128key) is misuse, _NOT_ textbook
> HKDF usage example as Nikita mentioned.
> hash_hkdf("sha256", $rsa128key, 0, '', $random256salt) is correct/designed
> usage.
>
>
>
> Reason Why Nikita and Andrey misunderstood the RFC:
>
> They ignored previously explained descriptions and cherry picked irrelevant
> statements in the RFC.
>
> Application of HKDF: https://tools.ietf.org/html/rfc5869#section-4
> -
>On the other hand, it is anticipated that some applications will not
>be able to use HKDF "as-is" due to specific operational requirements,
>or will be able to use it but without the full benefits of the
>scheme.  One significant example is the derivation of cryptographic
>keys from a source of low entropy, such as a user's password.  The
>extract step in HKDF can concentrate existing entropy but cannot
>amplify entropy.  In the case of password-based KDFs, a main goal is
>to slow down dictionary attacks using two ingredients: a salt value,
>and the intentional slowing of the key derivation computation.  HKDF
>naturally accommodates the use of salt; however, a slowing down
>mechanism is not part of this specification.
> -
>
> Especially this part
>
> -
>the derivation of cryptographic
>keys from a source of low entropy, such as a user's password.  The
>extract step in HKDF can concentrate existing entropy but cannot
>amplify entropy.
> -
>
> It says HKDF cannot be used with low entropy/weak keys("IKM"). This
> supports
> their opinion.
>
> However, these are explanations for __"Invalid/Wrong HKDF usage"__ as
> "Password
> hashing like PBKDF2". These are __irrelevant__ for "Valid/Correct HKDF
> usage" at
> all. i.e. This basically says "Hey, you shouldn't use HKDF for password
> hashing "as-is".
> HKDF is not password h

Re: [PHP-DEV] Wiki karma request

[Joe Watkins]

Granted

Cheers
Joe

On Mon, Sep 11, 2017 at 1:12 AM, Haitao Lv  wrote:

> Username: lvht
>
> Access requested: Wiki create
>
> Reason: Create RFC for feature of Fiber (sackful coroutine) support.
>
> Thanks.
>
> Haitao Lv
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] A validator module for PHP7

[Yasuo Ohgaki]

On Tue, Sep 12, 2017 at 1:04 PM, Stephen Reay 
wrote:

>
> On 12 Sep 2017, at 04:07, Yasuo Ohgaki  wrote:
>
> Stephen,
>
> On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay 
> wrote:
>
>>
>> On 11 Sep 2017, at 17:41, Yasuo Ohgaki  wrote:
>>
>> Hi Stephen,
>>
>> On Mon, Sep 11, 2017 at 6:37 PM, Stephen Reay 
>> wrote:
>>
>> On 11 Sep 2017, at 15:42, Yasuo Ohgaki  wrote:
>>
>> It seems you haven't try to use filter module seriously.
>> It simply does not have enough feature for input validations.
>> e.g. You cannot validate "strings".
>>
>>
>> Yasuo,
>>
>> I’ve asked previously what your proposal actually offers over the filter
>> functions, and got no response, so please elaborate on this?
>>
>>
>>
>> Can you show a concrete example that cannot be validated in user land
>> currently, using the filter functions as a base?
>>
>>
>> FILTER_VALIDATE_REGEXP is not good enough simply.
>> PCRE is known that it is vulnerable to regex DoS still. (as well as
>> Oniguruma)
>> Users should avoid regex validation whenever it is possible also to avoid
>> various
>> risks.
>>
>> In addition, current filter module does not provide nested array
>> validation
>> array key validation, etc. It's not true validation neither. It does not
>> provide
>> simple length, min/max validations. It does non explicit conversions (i.e.
>> trim), etc.
>> Length, min/max validation is mandatory validation if you would like to
>> follow
>> ISO 27000 requirement.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>>
>>
>> So, you still didn’t actually provide an example. I *guess* you’re
>> talking about character class validation or something else equally
>> “simple”, because I can’t imagine what else would be a common enough case
>> that you’d want to have built-in rules for, and that you wouldn’t
>> internally use RegExp to test anyway.
>>
>
> Your request is like "Devil's Proof". Example code that cannot do things
> with existing API cannot exist with meaningful manner. It can be explained
> why it cannot, though. Try what "validate" string validator can do,
> Then you'll see.
>
> $input = [
>   'defined_but_should_not_exist' => 'Developer should not allow unwanted
> value',
>   '_invalid_utf8_key_should_not_be_allowed_' => 'Developer should
> validate key value as well',
>   'utf8_text' => 'Validator should be able to allow UTF-8 and validate its
> validity at least',
>   'default_must_be_safe' => 'Crackers send all kinds of chars. CNTRL chars
> must not be allowed by default',
>   'array' => [
>'complex' => 1,
>'nested' =>  'any validation rule should be able to be applied',
>'array' => 1,
>'key_should_be_validated_also' => 1,
>'array' => [
>'any_num_of_nesting' => 'is allowed',
> ],
>   ],
>   'array_num_elements_must_be_validated' => [
>   "a", "b", "c", "d", "e", "f", "and so on", "values must be able to
> be validated as user wants",
>   ],
> ];
>
> There is no STRING validation filter currently. This fact alone,
> it could be said "filter cannot do string validation currently".
>
> List of problems in current validation filter
>  - no STRING validator currently
>  - it allows any inputs by default
>  - it does not allow multiple rules that allows complex validation rules
> for string
>  - it does not have callback validator
>  - it does not have key value validation (note: PHP's key could be binary)
>  - it does not validate num of elements in array.
>  - it cannot forbids unwanted elements in array.
>  - it cannot validate "char encoding".
>  - it does not enforce white listing.
>  - and so on
>
> These are the list that "filter" cannot do.
>
> Ok so we can’t use filter_var() rules to validate that a string field is
>> an Alpha or AlphaNum, between 4 and 8 characters long (technically you
>> could pass mb_strlen() to the INT filter with {min,max}_range options set
>> to get the length validation, but I’ll grant you that *is* kind of a crappy
>> workaround right now)
>>
>> Why not stop trying to re-invent every single feature already present in
>> PHP (yes, I’ve been paying attention to all your other proposals), and just
>> *add* the functionality that’s missing:
>>
>
> https://wiki.php.net/rfc/add_validate_functions_to_filter
> It's _declined_.  You should have supported this RFC if you would like to
> add features to filter.
> (I'm glad there is a new RFC supporter regardless of occasion)
>
> I don't mind this result much.
> Adding features to "filter" has some of shortcomings mentioned above
> even with my proposal.
>
> A `FILTER_VALIDATE_STRING` filter, with “Options” of `min` => ?int, `max`
>> => ?int and “Flags” of FILTER_FLAG_ALPHA, FILTER_FLAG_NUMERIC (possibly a
>> built in bit mask “FILTER_FLAG_ALPHANUMERIC” ?)
>>
>
> Simply adding these wouldn't work well as validator because
>
>  - Filter is designed for black listing
>
> As you may know, all of security standards/guidelines require
>
>  - White listing for validation
>
> We may change "filter", 

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Christoph M. Becker]

On 12.09.2017 at 16:52, Levi Morrison wrote:

> On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
>  wrote:
>>
>> Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :
>>
>>> Even if these issues could be resolved, I still think allowing both
>>> case-sensitive and case-insensitive constant identifiers does more harm
>>> than good, so either case-sensitive or case-insensitive constant
>>> identifiers should be removed from the language.  Since case-sensitive
>>> constant identifiers are already the default, and HHVM doesn't even
>>> support case-insensitive identifiers at all, I would suggest to remove
>>> case-insensitive constant identifiers.
>>>
>>> This could be implemented by triggering E_DEPRECATED whenever the third
>>> argument to define() is TRUE in PHP 7.3, and to remove this parameter
>>> altogether in PHP 8.  Most likely some further simplification in the
>>> engine could be done then as well.
>
> […] However, if we change only the case
> sensitivity of constants we gain little value for our BC break.

I have not suggested to *change* the case sensivity of constants, but
rather to settle on a common case – since `const` constants are always
case-sensitive, it appears that this should be so for define'd
constants.  This would make code as the following to work as expected:

  a.php
  

  b.php
   true
  echo FOO; // => bar - WFT?
  ?>

And it obviously would fix a bug.  IMHO, that is sufficient gain for a
presumably moderate BC break.

Please note, that I do not want to pursue a discussion regarding
changing all constants to be case-sensitive or all functions and class
names to be case-insensitive.  Of course, it is fine to discuss it, but
it is clearly out of scope for what I'm trying to improve (in my
opinion) here, which is more in the "a bird in the hand is worth two in
the bush" corner.

If it will be decided that all constant identifiers should be
case-insensitive, I'd be fine with it (not happy, though).  Probably, I
should reword the RFC to reflect that it is actually about deprecation
and removal of the third parameter of define() (plus preventing any
extension to register constants which do not conform to the "default"
casing).  In short: don't have two kinds of constants wrt. spelling
(true, false, null are not covered, since they are special anyway and
could be promoted to keywords).

-- 
Christoph M. Becker

-- 
Christoph



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Christoph M. Becker]

On 12.09.2017 at 21:55, Sara Golemon wrote:

> On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev  
> wrote:
>
>> I'm worried about TRUE vs. True vs. true though - I've see all of those used
>> around the code (not tRuE though ;) and breaking that would add a ton of
>> meaningless work to maintainers without any upside. Same with NULL/null etc.
>
> We could always special case these in the lexer, or during
> compile-time constant folding.  I agree they're a concern (and already
> noted as much in my previous reply), but they're an entirely tractable
> concern.

Sorry, I forgot to mention these special constants which are reserved
words right now.  Of course, these have to stay case-insensitive, and we
simply could promote them to keywords which are case-insensitive, anyway.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Levi Morrison]

On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins  wrote:
> On 12 September 2017 17:45:46 BST, Levi Morrison  wrote:
>>The rest of my message only makes sense once you understand I was
>>proposing unified case sensitivity for all symbols *and* merging them
>>into one table.
>
> Ah, OK, so I partially missed the point. I'm still not sure what you're 
> suggesting is sensible, though...
>
>
>>> If we want function and class references, they should have their own,
>>>unambiguous, syntax.
>
> I stand by this assertion. Consider the following statement:
>
> $foo = bar;
>
> Even if "bar" cannot *simultaneously* be the name of a function, a class, and 
> a constant, it can still *potentially* be any of the three, from the point of 
> view of the compiler.

If it's known, it's known, and it can proceed with that type. If it's
not known then autoload and proceed like normal. I fail to see how
this is an issue, and in fact, see it as a *significant* improvement
to our current situation...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Sara Golemon]

On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev  wrote:
> I don't think HHVM not supporting something can be an argument.
>
I agree there, though I will offer that part of the reason HHVM has
never bothered to support case-insensitive constants is that it's
simply never needed to.  The only major project that didn't work out
of the box was Wordpress, and when they saw my blogpost about their
one case-insensitive constant, they switched it to being
case-sensitive, because EVEN WORDPRESS thought they'd maintained that
BC long enough. :)

> I'm worried about TRUE vs. True vs. true though - I've see all of those used
> around the code (not tRuE though ;) and breaking that would add a ton of
> meaningless work to maintainers without any upside. Same with NULL/null etc.
>
We could always special case these in the lexer, or during
compile-time constant folding.  I agree they're a concern (and already
noted as much in my previous reply), but they're an entirely tractable
concern.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Stanislav Malyshev]

Hi!

> case-insensitive constant.  This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> .  See an example created by Nikita to see
> some probably unexpected behavior: .

The latter case probably should be fixed by not allowing second constant
to be defined. If you already have case-insensitive constant, it should
cover all of those.

> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good, so either case-sensitive or case-insensitive constant
> identifiers should be removed from the language.  Since case-sensitive
> constant identifiers are already the default, and HHVM doesn't even
> support case-insensitive identifiers at all, I would suggest to remove
> case-insensitive constant identifiers.

I don't think HHVM not supporting something can be an argument. I'm
worried about TRUE vs. True vs. true though - I've see all of those used
around the code (not tRuE though ;) and breaking that would add a ton of
meaningless work to maintainers without any upside. Same with NULL/null etc.

I am also not convinced those constants are really that bad. I'd
probably be fine with phasing out manual defines for case-insensitives
though. But I'm not sure what purpose it would serve then - the engine
would still have to support it, no?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Rowan Collins]

On 12 September 2017 17:45:46 BST, Levi Morrison  wrote:
>The rest of my message only makes sense once you understand I was
>proposing unified case sensitivity for all symbols *and* merging them
>into one table.

Ah, OK, so I partially missed the point. I'm still not sure what you're 
suggesting is sensible, though...


>> If we want function and class references, they should have their own,
>>unambiguous, syntax.

I stand by this assertion. Consider the following statement:

$foo = bar;

Even if "bar" cannot *simultaneously* be the name of a function, a class, and a 
constant, it can still *potentially* be any of the three, from the point of 
view of the compiler. 

So, far from allowing us to make nice inferences about function references vs 
strings-that-look-callable, we have now *broken* assumptions we could 
previously have made.

It seems like we'd just be adding another equally ambiguous way of writing the 
same code.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Sara Golemon]

On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker  wrote:
> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good.
>
+0.1 to removing case-insensitive constants, though we'd need to
define both "null" and "NULL" (similar for true and false) since
there's little consensus on which version of these constants get used
from project to project.  Also: While deprecating for 7.3 is fine, I'd
favor waiting for 8.0 for full removal.

As to François' suggestion to make the whole language case-sensitive?
Yeesh, that feels like a much more aggressive movement.  In the case
of constants they very nearly are case-sensitive only since, as you
point out, common practice is to not pass true for that third
parameter, and to prefer `const` over `define` anyway.  Identifiers
are another matter since they're insensitive by default.

In the case of classnames I could almost get on board since
autoloading standards have pushed users naturally in the direction of
respecting case sensitive as a coding standard.  I don't feel as
though that's true of functions or of projects where autoloaders
aren't used (not a small number).

Overall: No.  I'm -1 on making non-constant identifiers
case-sensitive.  At best, I'd perhaps get on board with a
declare(case_sensitivity=1); style directive.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] JSON_THROW_ON_ERROR

[Jakub Zelenka]

On Sun, Sep 10, 2017 at 2:24 AM, Andrea Faulds  wrote:

> Hi everyone,
>
> Craig Duncan previously sparked discussion here about JSON's
> error-handling behaviour. Unfortunately, his attempt to change it seems not
> to have gone anywhere, but I have his blessing to try this other approach
> instead.
>
> So here's an RFC: https://wiki.php.net/rfc/json_throw_on_error
>
> The feature can be described in a single paragraph (in fact, the title is
> pretty much enough, the patch is just detail) but it's better to go through
> the proper RFC process.
>
> Please tell me what you think.
>
>
I think that it makes sense in general. There are just couple of things
that are not described in RFC.

Currently it has higher priority than JSON_PARTIAL_OUTPUT_ON_ERROR. I think
that if someone specify this constant, then the partial output is required
and it should be preferred. In any case I think it should be in the RFC
what the behavior is.

Another thing is the logic of setting global json error. Currently it just
reset the error value so the next call to json_last_error() will return 0
(no error) even though there was an error which is in the exception code. I
think that the behavior should be either not resetting the global error
value at all (the previous error should be kept) or setting the global
error value so the json_last_error returns the same value as exception code
or 0 if no error. Again it would be good to mention the behavior in the RFC
so we prevent a new discussion in the PR... :)

Cheers

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Levi Morrison]

> Apologies if I've completely missed the point here.

Oh well, it happens.

> Are you saying that without case sensitivity, the language could deduce that 
> sum2 in that case was a function reference? That seems optimistic: not only 
> can you have a class, a constant, and a function all with the same name, but 
> you can't actually know which exists until the line is executed, because all 
> three can be defined at any time.

Close. If we make case sensitivity consistent (either all insensitive
or all sensitive) *and* merge symbol tables then we can get actual
features out of it. As it stands just changing the case sensitivity
does not buy as any features for our BC break.

The rest of my message only makes sense once you understand I was
proposing unified case sensitivity for all symbols *and* merging them
into one table.

>>array_map(sum2, $input1, $input2);
>>
>>Currently that requires `sum2` to be a constant.
>
> I'm not clear what this has to do with case sensitivity; the problem here is 
> that we don't have a type of "function reference" (nor "class reference") so 
> simulate such references with strings and runtime assertions.

This confusion stems from the aforementioned items.

> If we want function and class references, they should have their own, 
> unambiguous, syntax.

My point was rather that if we fix our inconsistency issues and merge
the tables no such syntax is required; all existing syntax works.
There are engine changes that have to accompany those as well,
obviously.

In summary I think changing constant case sensitivity is too small of
a step to gain us anything, but would be *very* happy to take it
further because it will give us actual features for our trouble.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Rowan Collins]

On 12 September 2017 15:52:38 BST, Levi Morrison  wrote:
>array_map(sum2, $input1, $input2);
>
>Currently that requires `sum2` to be a constant. 

I'm not clear what this has to do with case sensitivity; the problem here is 
that we don't have a type of "function reference" (nor "class reference") so 
simulate such references with strings and runtime assertions.

Are you saying that without case sensitivity, the language could deduce that 
sum2 in that case was a function reference? That seems optimistic: not only can 
you have a class, a constant, and a function all with the same name, but you 
can't actually know which exists until the line is executed, because all three 
can be defined at any time.

This kind of ambiguous syntax is precisely what I was trying to reduce by 
deprecating "undefined constant as string", and a similar "convenient fallback" 
(from current to global namespace) is currently the biggest thing blocking 
function autoloading.

If we want function and class references, they should have their own, 
unambiguous, syntax.

Apologies if I've completely missed the point here.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Merging LDAP controls support

[Côme Chilliet]

Hello,

I’m getting close to have something I can merge in master for my PR adding 
support for LDAP controls: https://github.com/php/php-src/pull/2640

In this case am I suppose to squash the changes in a single commit? This was 
suggested to me for a previous PR but there is so much changes here I feel we 
should keep the history.

If some of you can pull my branch and launch the tests from ext/ldap it would 
help. You’ll need an LDAP server and to fill the env vars from 
ext/ldap/tests/connect.inc.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Levi Morrison]

> By itself this change provides little value. If it was done in
> connection with other features such as merging symbol tables then we
> can actually gain some significant improvements:
>
> array_map(sum2, $input1, $input2);
>
> Currently that requires `sum2` to be a constant. To get the correct
> behavior we currently need to do:
>
> array_map('fully\qualified\namespace\sum2', $input1, $input2);

After rewriting my reply I noticed this sentence doesn't quite make sense:

> This is not just convenience; it provides safety to refactoring and
> general code analysis tools.

Instead I meant that using the string is not just inconvenient; it
also prevents fully-safe code refactoring and analysis.

> Maintenance is a crucial aspect of large
> code bases and being able to move away from stringly-typed things is a
> significant improvement. It's also a step towards general autoloading
> instead of just class/trait/interface autoloading; however this would
> require further changes.
>
> I believe these improvements would be worth it and do understand it is
> a large backwards compatibility break. Given sufficient time and
> tooling to prepare I think PHP would be markedly better in the
> long-run for these two changes. However, if we change only the case
> sensitivity of constants we gain little value for our BC break.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Levi Morrison]

On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
 wrote:
> Hi,
>
> Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :
>>
>> Hi everybody!
>>
>> Usually constant identifiers are treated case-sensitive in PHP.  This is
>> always the case for constants defined via a `const` declaration.
>> However, define() allows to pass TRUE as third argument to define a
>> case-insensitive constant.  This feature appears to potentially result
>> in confusion, and also causes bugs as shown in
>> .  See an example created by Nikita to see
>> some probably unexpected behavior: .
>>
>> Even if these issues could be resolved, I still think allowing both
>> case-sensitive and case-insensitive constant identifiers does more harm
>> than good, so either case-sensitive or case-insensitive constant
>> identifiers should be removed from the language.  Since case-sensitive
>> constant identifiers are already the default, and HHVM doesn't even
>> support case-insensitive identifiers at all, I would suggest to remove
>> case-insensitive constant identifiers.
>>
>> This could be implemented by triggering E_DEPRECATED whenever the third
>> argument to define() is TRUE in PHP 7.3, and to remove this parameter
>> altogether in PHP 8.  Most likely some further simplification in the
>> engine could be done then as well.
>>
>> Thoughts?
>
>
> What about making PHP 8 100% case-sensitive (except true/false) ? If we
> announce it years in advance, it is possible, IMO.
>
> Regards
>
> François
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

By itself this change provides little value. If it was done in
connection with other features such as merging symbol tables then we
can actually gain some significant improvements:

array_map(sum2, $input1, $input2);

Currently that requires `sum2` to be a constant. To get the correct
behavior we currently need to do:

array_map('fully\qualified\namespace\sum2', $input1, $input2);

This is not just convenience; it provides safety to refactoring and
general code analysis tools. Maintenance is a crucial aspect of large
code bases and being able to move away from stringly-typed things is a
significant improvement. It's also a step towards general autoloading
instead of just class/trait/interface autoloading; however this would
require further changes.

I believe these improvements would be worth it and do understand it is
a large backwards compatibility break. Given sufficient time and
tooling to prepare I think PHP would be markedly better in the
long-run for these two changes. However, if we change only the case
sensitivity of constants we gain little value for our BC break.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Dan Ackroyd]

On 12 September 2017 at 14:04, Christoph M. Becker  wrote:
>
> I don't think we can do that.  Consider, for instance, ext/gd where all
> functions are actually in lower case, but I've seen a lot of code
> written in pascal or camel case to make the functions better readable, e.g.
>
>   imageCreateFromJpeg() vs. imagecreatefromjpeg()

It's pretty easy to imagine that if we had function autoloading,
creating an optional small backwards compatibility shim/library to
work around that problem would be pretty easy.

It's also the type of error that would be easy to add a deprecation
warning to in a late 7.x branch.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Christoph M. Becker]

On 12.09.2017 at 14:52, François Laupretre wrote:

> What about making PHP 8 100% case-sensitive (except true/false) ? If we
> announce it years in advance, it is possible, IMO.

I don't think we can do that.  Consider, for instance, ext/gd where all
functions are actually in lower case, but I've seen a lot of code
written in pascal or camel case to make the functions better readable, e.g.

  imageCreateFromJpeg() vs. imagecreatefromjpeg()

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Niklas Keller]

2017-09-12 14:02 GMT+02:00 Christoph M. Becker :

> Hi everybody!
>
> Usually constant identifiers are treated case-sensitive in PHP.  This is
> always the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a
> case-insensitive constant.  This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> .  See an example created by Nikita to see
> some probably unexpected behavior: .
>
> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good, so either case-sensitive or case-insensitive constant
> identifiers should be removed from the language.  Since case-sensitive
> constant identifiers are already the default, and HHVM doesn't even
> support case-insensitive identifiers at all, I would suggest to remove
> case-insensitive constant identifiers.
>
> This could be implemented by triggering E_DEPRECATED whenever the third
> argument to define() is TRUE in PHP 7.3, and to remove this parameter
> altogether in PHP 8.  Most likely some further simplification in the
> engine could be done then as well.
>
> Thoughts?
>

+1

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[François Laupretre]

Hi,

Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :

Hi everybody!

Usually constant identifiers are treated case-sensitive in PHP.  This is
always the case for constants defined via a `const` declaration.
However, define() allows to pass TRUE as third argument to define a
case-insensitive constant.  This feature appears to potentially result
in confusion, and also causes bugs as shown in
.  See an example created by Nikita to see
some probably unexpected behavior: .

Even if these issues could be resolved, I still think allowing both
case-sensitive and case-insensitive constant identifiers does more harm
than good, so either case-sensitive or case-insensitive constant
identifiers should be removed from the language.  Since case-sensitive
constant identifiers are already the default, and HHVM doesn't even
support case-insensitive identifiers at all, I would suggest to remove
case-insensitive constant identifiers.

This could be implemented by triggering E_DEPRECATED whenever the third
argument to define() is TRUE in PHP 7.3, and to remove this parameter
altogether in PHP 8.  Most likely some further simplification in the
engine could be done then as well.

Thoughts?


What about making PHP 8 100% case-sensitive (except true/false) ? If we 
announce it years in advance, it is possible, IMO.


Regards

François

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Wiki karma request

[Joe Watkins]

Granted

Cheers
Joe

On Sun, Sep 10, 2017 at 6:04 PM, Larry Garfield 
wrote:

> Username: crell
>
> Access requested: Wiki edit
>
> Reason: Helping out Sara Golemon with logistics and paperwork for the
> short-lambda RFC, and collaborating on another RFC regarding
> comprehensions.
>
> Please!
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Deprecate and remove case-insensitive constants?

[Christoph M. Becker]

Hi everybody!

Usually constant identifiers are treated case-sensitive in PHP.  This is
always the case for constants defined via a `const` declaration.
However, define() allows to pass TRUE as third argument to define a
case-insensitive constant.  This feature appears to potentially result
in confusion, and also causes bugs as shown in
.  See an example created by Nikita to see
some probably unexpected behavior: .

Even if these issues could be resolved, I still think allowing both
case-sensitive and case-insensitive constant identifiers does more harm
than good, so either case-sensitive or case-insensitive constant
identifiers should be removed from the language.  Since case-sensitive
constant identifiers are already the default, and HHVM doesn't even
support case-insensitive identifiers at all, I would suggest to remove
case-insensitive constant identifiers.

This could be implemented by triggering E_DEPRECATED whenever the third
argument to define() is TRUE in PHP 7.3, and to remove this parameter
altogether in PHP 8.  Most likely some further simplification in the
engine could be done then as well.

Thoughts?

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php