Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

[Theodore Brown]

On Thu, Sep. 21, 2023 at 12:26 PM Tim Düsterhus wrote:

> I just opened the vote for the "Increasing the default BCrypt cost" RFC.
> The RFC contains a two votes, one primary vote that requires a 2/3
> majority to pass and a secondary vote deciding on the new costs with a
> simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC.
>
> Please find the following resources for your references:
>
> RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023

Hi Tim,

Thanks for your work on this. I think bumping the default BCrypt cost from 10 
to 11 is reasonable, as this typically adds less than 100 milliseconds 
additional latency, which shouldn't be too noticeable for users logging in.

However, I am concerned about changing the default directly from 10 to 12. Per 
the benchmarks in the RFC, even on recent hardware like the Apple M1 Pro this 
adds 179 ms additional time to verify a password (compared to 60 ms for the 
change to 11). This would be a noticeable slowdown for user logins.

It gets even worse on older hardware, with the example of the 2011 Core i5 
adding 247 milliseconds additional time at a cost of 12, vs. 81 ms additional 
time using a cost of 11.

It will be easy to bump the default cost again in the future, so I think a more 
gradual increase will be safer to avoid an obvious degradation to user login 
time.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Theodore Brown]

On Thu June 29, 2023 at 11:51 AM Theodore Brown wrote:
> On Tue, June 27, 2023, 6:33 Rowan Tommins wrote:
> > On 27/06/2023 02:25, Theodore Brown wrote:
> > > Currently the following code returns only the array keys that loosely 
> > > equal null:
> > >
> > >  array_keys($array, null)
> > >
> > > If the function is changed to a single signature with $filter_value 
> > > defaulting to null (with an argument count check to preserve the above 
> > > functionality), its behavior becomes a lot more surprising/unexpected. If 
> > > a parameter defaults to null, as a user I don't expect the function to 
> > > work differently when I explicitly pass the default value.
> >
> >
> > An alternative solution to this situation is to introduce a new dummy
> > value for such parameters, similar to how JavaScript uses the special
> > "Symbol" type to have keys that can't collide with any userland value.
> > In this context, this could be achieved with a single-value enum, i.e.:
> >
> > enum ArrayKeys { case IncludeAll; }
> >
> > function array_keys(array $array, mixed $filter_value =
> > ArrayKeys::IncludeAll, bool $strict = false): array {}
> >
> > That way, the optional parameter has a real default value, distinct from
> > any value the user might wish to filter by, including null, and full
> > compatibility is maintained with existing code.
>
> ...Note that currently there is a draft RFC to support objects in array keys. 
> [1] If that feature is accepted, would it not be allowed to filter array keys 
> by the `ArrayKeys::IncludeAll` enum value? That would also be 
> surprising/unexpected.


I must have been really tired when I wrote the above paragraph, because I 
forgot that the `filter_value` parameter matches against the value, not the key 
(so the Object Keys in Arrays RFC has nothing to do with it).

But this makes using an enum as the default `filter_value` even more 
problematic, since enums can already be used as array values and this would 
prevent filtering an array to return keys for this value. I.e. the following 
code would stop working: https://3v4l.org/5Br1a

So I still believe the overloaded array_keys signature should be deprecated for 
consistency and to avoid confusing behavior.

Best regards,
Theodore

[1]: https://wiki.php.net/rfc/object_keys_in_arrays
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Theodore Brown]

On Tue, June 27, 2023, 6:33 Rowan Tommins wrote:
> On 27/06/2023 02:25, Theodore Brown wrote:
> > Currently the following code returns only the array keys that loosely equal 
> > null:
> >
> >  array_keys($array, null)
> >
> > If the function is changed to a single signature with $filter_value 
> > defaulting to null (with an argument count check to preserve the above 
> > functionality), its behavior becomes a lot more surprising/unexpected. If a 
> > parameter defaults to null, as a user I don't expect the function to work 
> > differently when I explicitly pass the default value.
> 
> 
> An alternative solution to this situation is to introduce a new dummy
> value for such parameters, similar to how JavaScript uses the special
> "Symbol" type to have keys that can't collide with any userland value.
> In this context, this could be achieved with a single-value enum, i.e.:
> 
> enum ArrayKeys { case IncludeAll; }
> 
> function array_keys(array $array, mixed $filter_value =
> ArrayKeys::IncludeAll, bool $strict = false): array {}
> 
> That way, the optional parameter has a real default value, distinct from
> any value the user might wish to filter by, including null, and full
> compatibility is maintained with existing code.
> 
> I don't know whether this is a direction we want to go, but thought I'd
> throw it out there.


That's an interesting idea, but I'm not sure it would make the behavior any 
less confusing. Are single-value enums used like this anywhere else in PHP? As 
a user my expectation when seeing `ArrayKeys::IncludeAll` as the default is 
that there must be other `ArrayKeys` enum values for additional options.

Note that currently there is a draft RFC to support objects in array keys. [1] 
If that feature is accepted, would it not be allowed to filter array keys by 
the `ArrayKeys::IncludeAll` enum value? That would also be 
surprising/unexpected.

Based on the current vote tally, `array_keys` looks like it will be the only 
remaining function in PHP 9 with an overloaded signature, which would make it 
all the more strange.

[1]: https://wiki.php.net/rfc/object_keys_in_arrays
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

[Theodore Brown]

On Mon, June 26, 2023, at 14:43 Nikita Popov wrote:
> On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> >
> > I voted “no” on `array_keys()` because I do not see these as two different 
> > function signatures. To me, the single signature should look like this:
> >
> > function array_keys(array $array, ?mixed $filter_value = null, bool 
> > $strict = false): array {}
> >
> > I voted “no” on `IntlCalendar::set()` because it seems to me that 
> > `setDate()` and `setDateTime()` could share the same signature if `$hour`, 
> > `$minute`, and `$second` all default to zero, like this:
> >
> > public function setDate(int $year, int $month, int $dayOfMonth, int 
> > $hour = 0, int $minute = 0, int $second = 0): void {}
> >
> > In the same way, with `IntlGregorianCalendar::__construct()`, 
> > `createFromDate()` and `createFromDateTime()` could be combined as:
> >
> > public static function createFromDate(int $year, int $month, int 
> > $dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}
> 
> So commonality here is that these are all arity overloads.
> 
> I think there's three different kinds of overloads in involved in the RFC:
> 
> 1. static/non-static overloads. Support for this was dropped in PHP 8, but 
> had to be retained internally just for that one usage in FII, so getting rid 
> of that seems quite high value.
> 
> 2. type/meaning overloads, where certain parameters change meaning entirely 
> across overloads. These are incompatible with named parameters and result in 
> very unclear function signatures. They only become intelligible once split 
> into separate signatures, which is not something PHP supports. Removing these 
> is also fairly high value.
> 
> 3. arity overloads, where behavior depends on number of parameters, or 
> certain parameter counts are forbidden, but the actual meaning of the 
> parameters does not change. Equivalent to a func_num_args() check in userland 
> code. I think these arity overloads are pretty harmless. The function 
> signature is meaningful and compatible with named arguments.
> 
> My overall inclination here is to vote No on all the deprecations that 
> involve arity overloads and vote Yes on the remainder.
> 
> Possibly I'm missing some kind of complication that the arity overloads are 
> causing?


Currently the following code returns only the array keys that loosely equal 
null [1]:

array_keys($array, null)

If the function is changed to a single signature with $filter_value defaulting 
to null (with an argument count check to preserve the above functionality), its 
behavior becomes a lot more surprising/unexpected. If a parameter defaults to 
null, as a user I don't expect the function to work differently when I 
explicitly pass the default value.

To prevent confusion, the function would at least still need to be documented 
with two separate signatures in the PHP manual, which goes against one of the 
RFC goals of automatically updating signatures based on stubs.

So from my perspective there is value in deprecating arity overloads: it avoids 
confusing behavior changes and the need to manually keep the overloaded 
signatures documented and in sync in the manual.

Regards,
Theodore

[1]: https://3v4l.org/Sld4S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions

[Theodore Brown]

On Fri, Dec 16, 2022 at 5:09 PM Derick Rethans  wrote:
>On 16 December 2022 21:34:16 GMT, Theodore Brown  
>wrote:
>>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans  wrote:
>>
>>> Hi,
>>>
>>> I've just opened the vote for "More Appropriate Date/Time Exceptions".
>>> It runs until December 31st, 24:00 UTC.
>>>
>>> You can vote at:
>>> https://wiki.php.net/rfc/datetime-exceptions#voting
>>
>> Hi Derick,
>>
>> Thank you for your work on this. I like the idea of having more specific
>> exceptions to avoid having to parse generic exception/warning strings.
>>
>> However, I voted No because there doesn't seem to be an implementation
>> currently, and I'm concerned about introducing differences in error
>> handling between the procedural and object-oriented date functions.
>>
>> Is there a rational for why the procedural date functions should continue
>> producing generic warnings/exceptions, rather than consistently using the
>> same exception hierarchy as the OO interface? I fear this could make it
>> harder for users to switch between the procedural and OO APIs, as some
>> errors might have to be handled in a different way.
>>
>> Also, could maintaining parity between the procedural/OO APIs be more
>> difficult if they each implement error handling differently?
>> Perhaps I'm mistaken, but I thought that currently the procedural date
>> functions are simple aliases of the corresponding object method.
>
> You're mistaken then. The procedural versions never threw exceptions,
> and changing to that now is a big BC break, which is not warranted.
>
> It was always a deliberate choice (since 2014) that the procedural
> versions don't throw exceptions, and the OO versions do. The RFC is not
> wanting to change this behaviour. And rightfully so.

Thank you for the clarification. I know that the functions `date_create`
and `date_create_immutable` have this difference in behavior from the
`DateTime` and `DateTimeImmutable` constructors, and this is documented
in the PHP manual.

But for most other date functions there doesn't seem to be any difference.
E.g. `date_create_from_format` and `DateTime::createFromFormat` both return
false on failure.

Likewise, `date_interval_create_from_date_string` and 
`DateInterval::createFromDateString`
both output a warning and return false on failure, as do `date_modify` and 
`DateTime::modify`.
See https://3v4l.org/HjXee.

So I'm struggling to understand why it's okay to make a BC break for the OO API,
but not for the procedural API. As long as a BC break is being made, why not
change `date_create` and `date_create_immutable` throw exceptions like the
constructors, rather than trying to preserve BC for only the procedural API
and ending up with even more inconsistent behavior?

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions

[Theodore Brown]

On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans  wrote:

> Hi,
> 
> I've just opened the vote for "More Appropriate Date/Time Exceptions".
> It runs until December 31st, 24:00 UTC.
> 
> You can vote at:
> https://wiki.php.net/rfc/datetime-exceptions#voting

Hi Derick,

Thank you for your work on this. I like the idea of having more specific
exceptions to avoid having to parse generic exception/warning strings.

However, I voted No because there doesn't seem to be an implementation
currently, and I'm concerned about introducing differences in error
handling between the procedural and object-oriented date functions.

Is there a rational for why the procedural date functions should continue
producing generic warnings/exceptions, rather than consistently using the
same exception hierarchy as the OO interface? I fear this could make it
harder for users to switch between the procedural and OO APIs, as some
errors might have to be handled in a different way.

Also, could maintaining parity between the procedural/OO APIs be more
difficult if they each implement error handling differently?
Perhaps I'm mistaken, but I thought that currently the procedural date
functions are simple aliases of the corresponding object method.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Theodore Brown]

On Fri, Mar 18, 2022 at 09:02 Chase Peeler  wrote:
> On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown  
> wrote:
> > 
> > Personally I'm really looking forward to having this functionality.
> > Just a couple days ago I wanted to call a function in an interpolated
> > string, and it was really annoying to have to wrap the function in a
> > closure in order to use it.
> > 
> > If this RFC is accepted I'd be able to replace code like this:
> > 
> > $name = "Theodore Brown";
> > $strlen = fn(string $string): int => strlen($string);
> > echo "{$name} has a length of {$strlen($name)}.";
> > 
> > with
> > 
> > $name = "Theodore Brown";
> > echo "{$name} has a length of {$:strlen($name)}.";
> 
> 
> Out of curiosity, why not:
>
> $name = "Theodore Brown";
> echo "{$name} has a length of ".strlen($name).".";
> 
> or even
>
> $name = "Theodore Brown";
> $len = strlen($name);
> echo "{$name} has a length of {$len}.";

Concatenation works fine for a simple example like this, but it can
get a lot messier when there are more than a few embedded variables.
It's particularly an issue with heredoc strings which are far more
cumbersome to concatenate.

Yes, it's possible to add extra variables before the string like in
your second example, but this feels like unnecessary work, especially
when you already have all the variables you want and just want to
apply a function to them at several places in a template string.

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

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Theodore Brown]

On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm  wrote:

> On Thu, 17 Mar 2022, 23:27 Ilija Tovilo,  wrote:
>
>> Hi everyone
>>
>> I'd like to start discussion on a new RFC for arbitrary string
>> interpolation.
>> https://wiki.php.net/rfc/arbitrary_string_interpolation
>>
>> Let me know what you think.
>
> That is a cool idea.
> But I am not a big fan of having code in strings.
> Wouldn’t this open the door to all kinds of new attacks?

Do you have an example of a new kind of attack this would allow?
The proposal doesn't enable interpolation of strings coming from
a database or user input - it only applies to string literals
directly in PHP code.

Personally I'm really looking forward to having this functionality.
Just a couple days ago I wanted to call a function in an interpolated
string, and it was really annoying to have to wrap the function in a
closure in order to use it.

If this RFC is accepted I'd be able to replace code like this:

$name = "Theodore Brown";
$strlen = fn(string $string): int => strlen($string);
    echo "{$name} has a length of {$strlen($name)}.";

with

$name = "Theodore Brown";
echo "{$name} has a length of {$:strlen($name)}.";


Sincerely,

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

Re: [PHP-DEV] [RFC] Nullable intersection types

[Theodore Brown]

On Friday, July 23, 2021 at 4:58 AM Nicolas Grekas  
wrote:

> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote everything down about the reasons why here:
> https://wiki.php.net/rfc/nullable_intersection_types
>
> Please have a look and let me know what you think.


Hi Nicolas,

Thanks for your work on this. The RFC states:

> the preference of the author of this RFC is to define “?” as having
> a lower precedence than any other type-operator, and thus to use
> the “?X” syntax.

I also strongly believe this would be a mistake. When union types
were introduced, it was explicitly decided not to use the `?(T1|T2)`
syntax, for the following reason [1]:

> this notation is both rather awkward syntactically, and differs from
> the well-established `T1|T2|null` syntax used by phpdoc comments. The
> discussion feedback was overwhelmingly in favor of supporting the
> `T1|T2|null` notation.

`?T` is a shorthand alias for `T|null`, and the alias cannot be used
to add `null` to a union type.

Although PHP doesn't yet support generalized union and intersection
type combinations, this is almost certainly something we'll want to
enable in the future (in fact, this very RFC is a step towards this).

But if union types don't support the shorthand nullability syntax,
and intersection types require it, how will the syntaxes be combined
in the future? E.g. will we write `null | A & B | C` or will it be
required to use something like `?A & B | C`?

The latter is not only syntactically awkward but also very confusing.

Since `|null` is the only supported syntax to add `null` to a union
type, for consistency the same syntax should be used to add `null` to
an intersection type. This will avoid confusion and inconsistency
down the road if a future RFC enables more general union and
intersection type combinations. It also avoids the need to define a
precedence for the `?` type operator.

As you note in the RFC, PHP already defines `|` as having a lower 
precedence than `&`, so `X & Y | null` can only be interpreted as
`(X & Y) | null`. This is consistent with other languages such as
TypeScript, where `A & B | C & D` is parsed as `(A & B) | (C & D)`.
[2]

Since precedence is already defined for this syntax consistently with
other languages, I don't think it's necessary to require parentheses
if we use the `A & B | null` syntax.

Best regards,  
Theodore


[1]: https://wiki.php.net/rfc/union_types_v2#nullable_union_types
[2]: https://github.com/Microsoft/TypeScript/pull/3622

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

Re: [PHP-DEV] [VOTE] noreturn type

[Theodore Brown]

On Tue, Mar 30, 2021 at 5:24 PM Matthew Brown  wrote:

> On Tue, 30 Mar 2021 at 12:55, Theodore Brown  wrote:
> 
> > On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown  
> > wrote:
> > 
> > > Hey everyone!
> > >
> > > The vote for adding noreturn is now open:
> > >
> > > https://wiki.php.net/rfc/noreturn_type
> > >
> > > Voting will run through April 13th
> > 
> > Hi Matt and Ondrej,
> > 
> > Thanks for your work on this RFC. I voted for `never` as the type name
> > because it's more amenable to future use cases like compile-time
> > exhaustiveness checks (example:
> > https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type).
> > 
> > As a bonus `never` is more concise, avoids mashing two words together,
> > and aligns with TypeScript, which I and many other PHP devs also use.
> 
> Awesome! The conciseness argument for "never" is already mentioned in
> the RFC, as is TypeScript's use of the term.
> 
> Full disclosure (because neither of us is eligible to vote):
> I slightly prefer "noreturn", and Ondrej strongly prefers "never".

Hi Matt,

I'm confused by this. If Ondrej strongly prefers `never`, why does the
RFC say "we believe `noreturn` is the best name for this type"?

It might be better to just remove this sentence, or else list your separate 
preferences.

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

Re: [PHP-DEV] [VOTE] noreturn type

[Theodore Brown]

On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown  wrote:

> Hey everyone!
> 
> The vote for adding noreturn is now open:
> 
> https://wiki.php.net/rfc/noreturn_type
> 
> Voting will run through April 13th

Hi Matt and Ondrej,

Thanks for your work on this RFC. I voted for `never` as the type name
because it's more amenable to future use cases like compile-time
exhaustiveness checks (example:
https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type).

As a bonus `never` is more concise, avoids mashing two words together,
and aligns with TypeScript, which I and many other PHP devs also use.

Kind regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Add is_list(mixed $value): bool to check for list-like arrays

[Theodore Brown]

On Sun, Jan 3, 2021 at 8:56 PM Larry Garfield  wrote:

> On Sun, Jan 3, 2021, at 12:17 PM, tyson andre wrote:
> > > I've created the RFC https://wiki.php.net/rfc/is_list
> > >
> > > This adds a new function `is_list(mixed $value): bool` that will
> > > return true if the type of $value is array and the array keys are
> > > `0 .. count($value)-1` in that order.
> > >
> > > It's well-known that PHP's `array` data type is rare among
> > > programming languages in that it supports both integer and string
> > > keys and that iteration order is important and guaranteed. (it is
> > > used for overlapping use cases - in many other languages, both
> > > vectors/lists/arrays and hash maps are available)
> > >
> > > While it is possible to efficiently check that something is an
> > > array, that array may still have string keys, not start from 0,
> > > have missing array offsets, or contain out of order keys.
> > >
> > > It can be useful to verify that the assumption that array keys
> > > are consecutive integers is correct, both for data that is being
> > > passed into a module or for validating data before returning it
> > > from a module. However, because it's currently inconvenient to do
> > > that, this has rarely been done in my experience.
> > >
> > > In performance-sensitive serializers or data encoders, it may
> > > also be useful to have an efficient check to distinguish lists
> > > from associative arrays. For example, json_encode does this when
> > > deciding to serialize a value as [0, 1, 2] instead of {“0”:0,“2”:1,“1”:1}
> > > for arrays depending on the key orders.
> > >
> > > Prior email threads/PRs have had others indicate interest in the
> > > ability to efficiently check if a PHP `array` has sequential
> > > ordered keys starting from 0
> > >
> > > https://externals.io/message/109760 “Any interest in a list type?”
> > > https://externals.io/message/111744 “Request for couple memory
> > > optimized array improvements”
> > > Implementation: https://github.com/php/php-src/pull/6070
> > > (some discussion is in the linked PR it was based on)
> >
> >
> > Due to concerns about naming causing confusion with theoretical
> > potential future changes to the language,
> > I've updated https://wiki.php.net/rfc/is_list to use the name
> > `is_array_and_list(mixed $value): bool` instead.
> > (e.g. what if php used the reserved word `list` to add an actual list
> > type in the future, and is_list() returned false for that.)
> >
> > I plan to start voting on the RFC in a few days.
>
>
> Possible alternative that's less clumsy: is_packed_array?


Hi Tyson,

Thanks for the proposal and implementation. I've wanted a function
that does this on numerous occasions, so I think it will be a good
addition to the standard library.

If I may chime in with Larry's suggestion: I think `is_packed_array`
would  a better name than `is_array_and_list`. The latter is potentially
confusing since it sounds like the value has more than one type.
`is_packed_array` makes it clearer that the function checks whether
the value is an array matching certain criteria. I think it also reads
better when used along with other functions. For example:

function is_associative_array(mixed $value) {
return is_array($value) && !is_packed_array($value);
// vs.
return is_array($value) && !is_array_and_list($value);
}

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] List of attributes

[Theodore Brown]

On Sat, Oct 31, 2020, at 5:06 AM, Rowan Tommins wrote:

> > This would be an artificial limitation on attributes to patch
> > over the inherent inconsistency of the grouped syntax for nested
> > attributes.
>
> There is no artificial limitation; there is a binary choice: does
> #[Foo] represent an object or a list with one item in? This is
> completely new syntax, so there is nothing for it to be inconsistent
> with other than itself.

It is very much an artificial limitation. Developers would be prevented
from declaring that an attribute must be passed a single attribute 
with a particular type as one of its parameters. This isn't a natural
or inherent limitation of attributes, but an artificial one in order
to try to make the `#[Attr1, Attr2]` grouped syntax usable with nested
attributes.

> I am arguing that having it represent a list with one item in is
> actually *more* consistent, because when you attach attributes to a
> declaration, they are always retrieved as a list.

That's not necessarily the case for nested attributes. A developer
may want to declare that an attribute constructor takes a single
attribute with a particular type as one of its arguments. Why should
PHP prevent this by only allowing a (possibly empty) list to be
passed? Again, this would be an artificial limitation that reduces
the flexibility and usefulness of nested attributes.

On Sat, Oct 31, 2020 at 7:38 PM Larry Garfield  wrote:

> Perhaps a naive question, but I'm missing the downside of:
> 
> #[Foo(Bar(name="baz"))]
> 
> #[Attribute]
> class Foo {
>   public function construct(public Bar $bar) {}
> }
> 
> class Bar {
>   public function construct(public string $name) {}
> }
> 
> Why is that not OK?  Someone mentioned it means you couldn't call a
> function there, but... that's not a huge problem because I can't
> imagine why you would.  If we really wanted to avoid that:
> 
> #[Foo(new Bar(name="baz"))]
>
> That would be unambiguous, if a bit ugly.

As I mentioned in my first email in this thread, there was an attempt
to do this back when the original `<<>>` attribute syntax was being
implemented. But this approach ran into difficulties since it would
require significant changes to constant expressions.

Even if someone finds a reasonable way to make such a syntax *work*,
it still has the downside of requiring a different syntax for top-
level and nested attributes (docblock annotations allow using the
same syntax for both). Moreover, re-purposing the syntax for function
calls or class instantiation is likely to cause confusion, since it
looks like the code is doing something other than what it actually
does (and of course it would prevent ever extending constant
expressions to support function calls or class instantiation).

One of my main motivations for proposing the `@@` shorter attribute
syntax was to avoid the complexity of grouped declarations and allow
using a single consistent syntax for both top level and nested
attributes. I fear that the change to the `#[]` syntax with grouping
will prevent PHP from getting a flexible and intuitive nested
attribute implementation, and devs will be forced to stick with
docblock annotations for these use cases.

Kind regards,  
Theodore

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

Re: [PHP-DEV] List of attributes

[Theodore Brown]

On Fri, Oct 30, 2020 at 2:28 PM Rowan Tommins  wrote:

> On 30/10/2020 18:47, Theodore Brown wrote:
> > While passing all nested attributes as an array would at least enable
> > consistent semantics, it has the notable disadvantage of preventing
> > some use cases from being expressed in PHP's type system. Specifically,
> > how would you express that an attribute parameter must be passed a
> > single attribute of a particular type?
> 
> I acknowledged this use case, but suspected, and still suspect, that
> it's rarer than the list-of-attributes case.
> 
> > For example, suppose a developer wants to create/use an attribute
> > like the following:
> >
> > #[Limit(
> > min: 10,
> > max: 100,
> > error: #[CustomError(message: "...", notify: true, withTrace: 
> > false)]
> > )]
> 
> What is the fundamental advantage of using an attribute as the argument
> here? The same thing can be expressed with an associative array:
> 
> #[Limit(
> min: 10,
> max: 100,
> error: ["message" => "...", "notify" => true, "withTrace" => false]
> )]
> 
> The only thing that seems to lose is the ability to specify the allowed
> names and types of options - but those won't be checked by the
> ReflectionAttribute anyway, only once the actual constructor is run.


The fundamental advantage of using an attribute here instead of an
associative array is that it enables IDE autocompletion, and allows
static analyzers to catch any mistakes in the parameter names/types
before the code runs in production.

> So there's nothing really "attribute-y" about the CustomError class,

What do you mean by "attribute-y"? The `CustomError` class would be a
normal attribute, and as such when calling `getArguments()` on the
`Limit` ReflectionAttribute it would return a ReflectionAttribute for
`CustomError`, which would allow its arguments to be inspected without
loading the class.

> and any "static object declaration" syntax would do, e.g.
> 
> #[Limit(
> min: 10,
> max: 100,
> error: CustomError{message="...", notify=true, withTrace=false}
> )]

It's not clear what exactly you're proposing here, or how it would work.
E.g. would this still allow inspecting the attribute arguments without
loading the `CustomError` class? Why is a new syntax needed for this?
Would it limit what the `CustomError` constructor is allowed to do? 


> > But if nested attributes are always passed as an array, the `$error`
> > parameter would have to have an `array` type, which provides
> > essentially no context about what is really required. The type system
> > would be perfectly happy to allow an empty array, or an array with
> > multiple values instead of the expected single `CustomError` attribute.
> 
> 
> Again, this is a general problem, not one related to attributes: the
> Symfony validation examples would be best declared as requiring
> "Constraint[] $constraints" rather than "array $constraints".

There is no general problem of not being able to specify that a
parameter takes a single object with a particular type. This would be
an artificial limitation on attributes to patch over the inherent
inconsistency of the grouped syntax for nested attributes.


> > 3. Vote to switch to a less verbose syntax [...]
> > The downside is that...
> 
> Let me stop you there. The downside is that a mob of Internals regulars
> will come to your house and lynch you for asking them to vote on the
> same thing yet again. It just ain't gonna happen.

I doubt anyone is more tired and worn out from discussing and voting
on attributes than I am. But there are serious issues when it comes to
supporting nested attributes with the #[] syntax and attribute grouping.
Shouldn't I bring them up and propose solutions before PHP 8 is released?

Best regards,  
Theodore

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

Re: [PHP-DEV] List of attributes

[Theodore Brown]

Hi Rowan and Nicolas (and internals),

On Wed, Oct 28, 2020 at 12:57 PM Rowan Tommins  wrote:

> On 28/10/2020 16:58, Nicolas Grekas wrote:
> > about why we'd need nested attributes, here is a discussion about
> > nested validation constraints:
> > https://github.com/symfony/symfony/issues/38503
> 
> Thanks, it's useful to see some real-world examples. As I suspected,
> nearly all of these explicitly take a *list* of nested attributes,
> not a single attribute.
> 
> > While most of the constraints receive the nested constraints as
> > simple array, |Collection| however requires a mapping (field to
> > constraint) and is usually combined with other composite
> > constraints, which gives us a second nesting level.
> 
> There is much discussion of Collection as an edge case, but although
> the nested attributes are indeed inside a mapping, the *value* of
> that mapping is again a list of attributes. Single items are allowed,
> but this seems to be a special case for convenience. ... This
> reinforces my earlier suggestion (https://externals.io/message/111936#112109)
> that #[Foo] in a nested context can simply imply an array of one
> attribute,


While passing all nested attributes as an array would at least enable
consistent semantics, it has the notable disadvantage of preventing
some use cases from being expressed in PHP's type system. Specifically,
how would you express that an attribute parameter must be passed a
single attribute of a particular type?

For example, suppose a developer wants to create/use an attribute
like the following:

#[Limit(
min: 10,
max: 100,
error: #[CustomError(message: "...", notify: true, withTrace: false)]
)]

I would expect to be able to write the `Limit` attribute class like this:

#[Attribute]
class Limit {
public function __construct(
public int $min,
public int $max,
public CustomError $error,
) {}
}

But if nested attributes are always passed as an array, the `$error`
parameter would have to have an `array` type, which provides
essentially no context about what is really required. The type system
would be perfectly happy to allow an empty array, or an array with
multiple values instead of the expected single `CustomError` attribute.

It may be possible to enable static analysis type checks and IDE
autocompletion by adding extra docblock annotations or attributes
specifying that the array has to contain exactly one `CustomError`
value, but this is a workaround requiring a lot more effort than
should be necessary. Overall the dev experience becomes a lot worse
for these use cases.


On Wed, Oct 28, 2020 at 11:58 AM Nicolas Grekas  
wrote:

> > The problem with this is that it results in inconsistent semantics,
> > where the number of items in an attribute group results in a
> > different type of value being passed. I.e. if you remove two of the
> > three attributes from the list, suddenly the code will break since
> > the `Assert\All` attribute is no longer being passed an array.
> 
> Yes.
> This would be solved by NOT accepting #[] inside attribute declarations.
> Since we borrowed from Rust, let's borrow this again:
> http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/attributes.html#attributes
> 
> The Rust syntax accepts the #[] only on the outside of the declaration.
> The example above should be written as:
>
> #[Assert\All([
> Assert\Email(),
> Assert\NotBlank(),
> Assert\Length(max: 100)
> ])]
> 
> The closing brackets () would be required to remove any ambiguity
> with constants. Since constant expressions won't ever allow functions
> in them, this isn't ambiguous with function calls.


This does seem more readable and also avoids the grouped syntax
inconsistency. On the other hand, presumably it would prevent ever
supporting function calls in constant expressions. At present I'm not
convinced constant expressions *should* support this, but nevertheless
I have reservations about a syntax choice that would rule it out
completely.

Furthermore, the requirement of parentheses seems inconsistent with
normal attribute declarations and `new ClassName` instantiations,
where parentheses are optional.

As I see it, we have the following other options:

1. Simply ban the grouped syntax in nested context. This has the
downside of extra verbosity and that it may be unexpected/surprising
for developers.

2. Drop support for attribute grouping before PHP 8 is finalized. Rust
(which we borrowed the `#[]` syntax from) itself does not support this
anyway. The primary downside of no attribute grouping is additional
verbosity in some circumstances.

   Note: a number of people who voted for `#[]` expressed disfavor of
attribute grouping, which was originally accepted only for the `<<>>`
syntax with the qualification that it would be superseded by any other
RFC that changes the syntax. [1]

3. Vote to switch to a less 

Re: [PHP-DEV] List of attributes

[Theodore Brown]

On Tue, Oct 20, 2020 at 10:13 AM Rowan Tommins  wrote:

> On Mon, 19 Oct 2020 at 16:17, Theodore Brown  wrote:
> 
> >
> > In theory nested attributes could be supported in the same way with
> > the `#[]` syntax, but it's more verbose and I think less intuitive
> > (e.g. people may try to use the grouped syntax in this context, but
> > it wouldn't work). Also the combination of brackets delineating both
> > arrays and attributes reduces readability:
> >
> > #[Assert\All([
> > #[Assert\Email],
> > #[Assert\NotBlank],
> > #[Assert\Length(max: 100)]
> > ])]
> >
> 
> I think you're presupposing how a feature would work that hasn't
> even been specced out yet. On the face of it, it would seem logical
> and achievable for the above to be equivalent to this:
> 
> #[Assert\All(
>#[
> Assert\Email,
> Assert\NotBlank,
> Assert\Length(max: 100)
>]
> )]
> 
> i.e. for a list of grouped attributes in nested context to be
> equivalent to an array of nested attributes.

Hi Rowan,

The problem with this is that it results in inconsistent semantics,
where the number of items in an attribute group results in a
different type of value being passed. I.e. if you remove two of the
three attributes from the list, suddenly the code will break since
the `Assert\All` attribute is no longer being passed an array.

// error when Assert\All is instantiated since it's no longer being  
// passed an array of attributes:

#[Assert\All(
#[
Assert\Email,
]
)]

So when removing nested attributes from a list such that there's only
one left in the list, you'd have to remember to additionally wrap the
attribute group in array brackets:

#[Assert\All(
[#[
Assert\Email,
]]
)]

And of course when you want to add additional attributes to a group
that originally had only one attribute, you'd have to remember to
remove the extra array brackets.

Generally speaking, having the number of items in a list change the
type of the list is a recipe for confusion and unexpected errors. So
I think the only sane approach is to ban using the grouped syntax in
combination with nested attributes.

Unfortunately, no one thought through these issues when proposing to
change the shorter attribute syntax away from @@ and add the grouped
syntax, and now it seems like we're stuck with a syntax that is 
unnecessarily complex and confusing to use for nested attributes.

> Unless nested attributes were limited to being direct arguments to
> another attribute, the *semantics* of nested attributes inside
> arrays would have to be defined anyway (e.g. how they would look in
> reflection, whether they would be recursively instantiated by
> newInstance(), etc).

Yes, the exact semantics of nested attributes need to be defined, but
this is a completely separate topic from the grouped syntax issue
described above.

As a user I would expect nested attributes to be reflected the same
as any other attribute (i.e. as a `ReflectionAttribute` instance).
Calling `getArguments` on a parent attribute would return an array
with `ReflectionAttribute` objects for any nested attribute passed
as a direct argument or array value.

On first thought I think it makes sense to recursively instantiate
nested attributes when calling `newInstance` on a parent attribute.
This would allow attribute class constructors to specify the type
for each attribute argument. But again, this is a separate discussion
from the issue of nested attribute syntax.

Kind regards,  
Theodore

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

Re: [PHP-DEV] List of attributes

[Theodore Brown]

On Mon, Oct 5, 2020 at 9:24 AM Nicolas Grekas  wrote:

>> I'm wondering if the syntax that allows for several attributes is
>> really future-proof when considering nested attributes:
>>
>>
>> *1.*
>> #[foo]
>> #[bar]
>>
>> VS
>>
>> *2.*
>> #[foo, bar]
>>
>> Add nested attributes to the mix, here are two possible ways:
>>
>> *A.*
>> #[foo(
>> #[bar]
>> )]
>>
>> or
>>
>>
>> *B.*
>> #[foo(
>> bar
>> )]
>>
>> The A. syntax is consistent with the 1. list. I feel like syntax
>> B is not desired and could be confusing from a grammar pov.
>> BUT in syntax 2., we allow an attribute to be unprefixed (bar),
>> so that syntax B is consistent with 2.
>>
>> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested
>> attributes are introduced?
>>
>> I voted yes for syntax 2. when the attributes were using << >>. I would
>> vote NO now with the new syntax.
>>
>> Nicolas
>
> As far as my understanding goes, if we introduce "nested" attributes, it
> will be in the form of relaxing constraints on constant expressions, i.e.
> by allowing you to write #[Attr(new NestedAttr)].
>
> Nikita

Back when the original `<<>>` attribute syntax was being implemented,
there was an attempt to do just this. But it turned out to be very
difficult to implement, and it was ultimately given up on since it
required significant changes to const expressions. Earlier this year
there was also a poll to gauge interest in supporting function calls
in constant expressions, but most voters opposed it. [1]

Even if a proposal for relaxing constraints on constant expressions
gains enough support, it's not clear this is the ideal path forward
for nested attributes, since as Nicolas pointed out this wouldn't
have the same lazy-loading semantics as existing attributes.

Straightforward support for nested attributes was one of my main
motivations for proposing the `@@` syntax in the Shorter Attribute
Syntax RFC, [2] and I had hoped to collaborate on a follow-up RFC to
support nested attributes with the AT-AT syntax. This would allow
existing nested docblock annotations such as Nicolas's example to
translate intuitively to native attributes:

@@Assert\All([
@@Assert\Email,
@@Assert\NotBlank,
@@Assert\Length(max: 100)
])

This would also preserve the lazy-loading feature where these
attribute classes aren't loaded until code calls `newInstance`
on one of the `ReflectionAttribute` objects.

But then the Shorter Attribute Syntax Change RFC [3] came along and
derailed this plan...

In theory nested attributes could be supported in the same way with
the `#[]` syntax, but it's more verbose and I think less intuitive
(e.g. people may try to use the grouped syntax in this context, but
it wouldn't work). Also the combination of brackets delineating both
arrays and attributes reduces readability:

#[Assert\All([
#[Assert\Email],
#[Assert\NotBlank],
#[Assert\Length(max: 100)]
])]

But at this point I assume this is the most viable path forward for
nested attributes (barring another syntax re-vote and delay of PHP 8).
I know Derick and Benjamin have stated they aren't in favor of nested
attributes and didn't put any thought into the syntax for them, but I
feel this is unfortunate since nested attributes are an established
pattern with legitimate use cases in existing libraries.

Best regards,  
Theodore

[1]: https://wiki.php.net/rfc/calls_in_constant_expressions_poll
[2]: https://wiki.php.net/rfc/shorter_attribute_syntax
[3]: https://wiki.php.net/rfc/shorter_attribute_syntax_change
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Should hash comments be deprecated?

[Theodore Brown]

Hi internals,

Since the #[] attribute syntax is currently winning the vote, [1]
it makes me wonder if the use of comments starting with # should be
deprecated.

Otherwise it seems like we could be setting ourselves up for long-term
confusion between attributes and comments, and also inconsistency with
other comments (it will no longer be safe to assume that a line can be
commented out by simply adding # at the beginning).

What do others think?

Theodore

[1]: https://stv-results.theodorejb.me/php/?rfc=shorter_attribute_syntax_change
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Theodore Brown]

On Thu, Aug 20, 2020 at 2:13 AM
Côme Chilliet  wrote:

> Le Wed, 19 Aug 2020 21:11:29 +, 
> Theodore Brown  a écrit :
> > In case anyone wants to view the in-progress STV vote results, I took
> > the same script I made for the Shorter Attribute Syntax RFC and made
> > it possible to run online here:
> >
> > https://stv-results.theodorejb.me/php/?rfc=shorter_attribute_syntax_change
> >
> > Note that at present it only processes the STV vote and ignores the
> > primary 2/3 poll result, so keep that in mind.
> 
> Thank you, I was searching for something like this!
> 
> Is there any chance we can see the code? (mostly out of curiosity)

Hi Côme,

Ask, and you will receive! https://github.com/theodorejb/php-stv

> Also, is it supposed to be updated at page load or at some time
> interval? I see 15 votes on the RFC page for #[] and 14 on your page.

It's currently updated on page load. As Benjamin suggested, there are
some invalid ballots right now where the same candidate was selected
more than once. You can view these by adding a `=1`
parameter to the URL. You can also have it output all counted ballots
by adding `=1` to the URL.

Note that the webpage works for other STV elections. If you set the
`rfc` parameter to "shorter_attribute_syntax", you can view the
results of the original Shorter Attribute Syntax RFC. If you replace
this parameter with `?election=todo/php80` you can view the PHP 8.0
release manager election results. [1]

Interestingly, it looks like Gabriel won this election rather than it
being a tie as was announced on list. [2] My guess is that Derick
possibly tallied the results before the poll was actually closed 
which caused a vote to be missed? At least the result didn't change
in the subsequent vote!

Kind regards,  
Theodore

[1]: https://stv-results.theodorejb.me/php/?election=todo/php80
[2]: https://externals.io/message/109552#109756
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Theodore Brown]

On Wed, Aug 19, 2020 at 11:09 AM Benjamin Eberlei  wrote:

> I wanted to clarify that this is the **restarted* vote on Shorter
> Attribute Syntax Change, that means all votes cast between August
> 11th and 15th have been reset.

In case anyone wants to view the in-progress STV vote results, I took
the same script I made for the Shorter Attribute Syntax RFC and made
it possible to run online here:

https://stv-results.theodorejb.me/php/?rfc=shorter_attribute_syntax_change

Note that at present it only processes the STV vote and ignores the
primary 2/3 poll result, so keep that in mind.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attributes Syntax Change

[Theodore Brown]

Hi Benjamin,

Thank you again for putting in the effort to update the RFC and
address most of the arguments brought up on list.

I would encourage everyone to read through the complete RFC before
voting, particularly the sections on BC breaks and forward
compatibility pros/cons. Top link:
https://wiki.php.net/rfc/shorter_attribute_syntax_change

The @{} syntax hasn't had much discussion yet. While I think it is
better than @[] and #[] since it doesn't break BC, it still shares
the problem of looking like a standalone block, when really
attributes are part of a class/function/property/etc. declaration.

Now that voters have the complete information, it's up to them to
make a final decision. I look forward to putting this issue behind us!

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei  wrote:

> https://wiki.php.net/rfc/shorter_attribute_syntax_change
> 
> I have updated the RFC one last time with as much of the feedback
> as possible:
> 
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and 
>   ultimately not that important as downstream libraries just have to
>   deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
> 
> I don't think something major is missing now.

Hi Benjamin,

Thanks for the updates. I just have a few more thoughts on aspects
that haven't been mentioned before:

1. The **Attributes are not like Modifiers** section makes an
   argument that having an end delimiter "groups docblock comment and
   attributes into two similarly shaped syntax blocks that prefix the
   declaration increasing familiarity."

In my own (admittedly subjective) opinion, an end delimiter on
attributes actually increases confusion when there is also a
docblock. To reuse the example from the RFC:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
#[
ORM\Entity(),
ORM\Table("baz")
]
final class Something {
}

Because the attribute group has its own start and end delimiters, it
almost looks like the doc comment applies to the attribute block
rather than the class.

With the `@@` or `@:` syntax, it seems clearer that attributes are
part of the class/function/property declaration, rather than their
own standalone construct which docblocks can be applied to:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
@@ORM\Entity
@@ORM\Table("baz")
final class Something {
}


Given that the only complex part of an attribute is the optional
argument list, which already has its own start/end delimiters, I
ultimately don't find the "complexity" argument very compelling for
needing an additional attribute end delimiter besides.


2. In the **Discussion on grep'ability** section, the RFC says
   "Enforcement of same line is also not the case for other
   declarations that benefit from grep'ability such as classes,
   functions, constants and so on in PHP already, so this is not
   consistent within the language."

This seems to be outdated information, based on Martin's original
patch before the "Treat namespaced names as single token" RFC was
accepted. In the current `@@` implementation, there is no single-line
enforcement, consistent with other parts of the language.

Not having whitespace between the attribute token and name would be
enforced by coding style conventions, just as is the case with
function/class/constant definitions.

Note that there is some precedent in PHP for choosing syntax that
ensures easier searching (for example, the decision to place return
type declarations after the parameter list rather than before the
function name).

Grep'ability isn't a big deal when finding usages in an IDE, but
sometimes there is a need to search code on a server or other source
without an IDE, in which case easy grep'ability can be very helpful.

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

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei  wrote:
> On Mon, Aug 17, 2020 at 5:14 PM Theodore Brown  wrote:
> > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
> > > > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > > > >
> > > > > The RFC shows an example of a potential "simpler" attribute using a
> > > > > string instead of a class name. I honestly have no idea what this is
> > > > > supposed to do or what benefit it would have over normal attributes.
> > > > >
> > > > > The concept of attributes being a class name with optional arguments
> > > > > has been proven over many years by its use in docblock annotations,
> > > > > and if there was some deficiency in what this syntax allows it seems
> > > > > like we would have discovered it by now.
> > > >
> > > > I agree on just the string, but a closure would make 100% sense for
> > > > a decorating feature. Javascript and Python "Attributes" work as
> > > > decorators, i.e. they get called around the decorated function.
> > > >
> > > > It is not a completely unrealistic feature to think off:
> > > >
> > > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > > > function foo($message) {}
> > >
> > > As I understand it JavaScript decorators do not use anonymous
> > > functions for decorators like this, though. Instead you would make a
> > > named function and apply it with `@myFunc()` before the decorated
> > > function or class.
> > >
> > > Presumably we could accomplish the same thing in PHP with e.g. an
> > > `__invoke` method in the attribute class, without complicating the
> > > attribute syntax itself.
> > 
> > One other thought on this. I agree that decorators are not a
> > completely unrealistic future feature. However, it must be noted that
> > both JavaScript and Python use the `@Attr` syntax for decorators, and
> > the lack of an end delimiter in no way precludes this usage.
> 
> Yes they support decorators with @, but they don't support metadata.
> 
> With this syntax its either or, because from @Attr only you cannot
> decide if its a decorator or a metadata attribute.
> 
> It would not work by detecting __invoke on the Attribute, because
> the whole architecture of Attributes is based on deferring
> autoloading until Reflection*::getAttributes(). But when you use
> decorators, you would need to know this at runtime, so the
> zend_attribute datastructure would need to know its not an metadata
> attribute, but a decorator.

Hi Benjamin,

That's true. Due to deferred loading we would need some kind of
new syntax to denote checked attributes or decorators, *regardless
of whether the attribute syntax has an end delimiter*. As I've
suggested before, we could potentially denote checked attributes
in the future like this:

@@!Attr("some val")
function foo() {...}

I still believe that using an inline closure attribute syntax like
the example in the RFC would not be a good solution for decorators,
as it reduces reusability and readability, and would prevent applying
a decorator that includes metadata.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown  wrote:

> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei  wrote:
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown  
> > wrote:
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > > The RFC shows an example of a potential "simpler" attribute using a
> > > string instead of a class name. I honestly have no idea what this is
> > > supposed to do or what benefit it would have over normal attributes.
> > >
> > > The concept of attributes being a class name with optional arguments
> > > has been proven over many years by its use in docblock annotations,
> > > and if there was some deficiency in what this syntax allows it seems
> > > like we would have discovered it by now.
> >
> > I agree on just the string, but a closure would make 100% sense for
> > a decorating feature. Javascript and Python "Attributes" work as
> > decorators, i.e. they get called around the decorated function.
> >
> > It is not a completely unrealistic feature to think off:
> >
> > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > function foo($message) {}
> 
> As I understand it JavaScript decorators do not use anonymous
> functions for decorators like this, though. Instead you would make a
> named function and apply it with `@myFunc()` before the decorated
> function or class.
> 
> Presumably we could accomplish the same thing in PHP with e.g. an
> `__invoke` method in the attribute class, without complicating the
> attribute syntax itself.

One other thought on this. I agree that decorators are not a
completely unrealistic future feature. However, it must be noted that
both JavaScript and Python use the `@Attr` syntax for decorators, and
the lack of an end delimiter in no way precludes this usage.

The whole point of a decorator is to offer syntax sugar for a common
reusable pattern (pass a function/class to another function which can
add additional information or behavior to it). It's not clear how an
anonymous closure would be useful for this, since it would not allow
reusability, which defeats the purpose.

So the argument that an end delimiter has "potential future benefits"
still lacks any realistic examples, and is countered by years of
proven usage of the `@Attr` syntax in docblocks and other languages.

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

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei  wrote:

> On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown  wrote:
> > However, ending delimiters in PHP have little to do with how "complex"
> > a syntax construct is (which is a rather loose definition, anyway).
> > As I've pointed out before, standalone statements and declarations
> > generally require an end symbol, but modifiers before a declaration
> > do not. Attributes fall into the latter category, and therefore the
> > lack of an end delimiter is consistent.
> 
> A docblock is also a "modifier" under your declaration and it has an
> ending symbol.

The difference is that a docblock comment is also a standalone 
declaration - it's quite common to add one at the top of a file
that doesn't modify any other declaration.

> The RFC gives a definition of the complexity as just a token vs a
> set of name, arugment_list and constant expression parser rules. It
> shows an example porting an ORM\JoinTable Attribute, which has
> arguments, named parameter usage, complex definitions of default
> values (Strings, arrays).
>
> This piece of code probably touches 10-20 parser rules.
>
> Most modifiers don't even have a parser rule, as they only match
> their token.

In this comparison really the only "complex" part of an attribute is
the argument list, which already has its own start and end delimiters.
So I don't really see the need to add another end delimiter after the
argument list end delimiter.

> Types are missing indeed, and they are more complex than a simple
> token, but less complex than attribute declarations.
>
> I guess the difference is that union types are new, and type
> definitions used to be simple. Attributes however are *new* and
> already complex, so we still have the option of always enclosing
> them.

An attribute without arguments has essentially the same complexity
that a type declaration has always had. The only part that is more
complex is the optional argument list, which as stated before has
its own start/end delimiters.

> > The RFC suggests a benefit of "Consistent colouring for being an
> > end of the attribute syntax and the keywords in between can use
> > different colors." I don't really understand this argument. How
> > would an end delimiter change the syntax highlighting provided by
> > IDEs?
> 
> If you consider the three elements of an attribute declaration:
> 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if
> you color them in three different ways, then with an ending symbol
> it improves the human readability to have the end be in the same
> color [as] the beginning.

I see what you mean now. Personally I don't think a differently
colored end bracket will be particularly helpful to readability,
though. IDEs will already highlight the argument list start/end
delimiters, and the different coloring of an attribute name from
whatever token follows it will ensure readability whether there is
an argument list or not. Ultimately perspectives on readability will
differ, though, since it's a somewhat subjective consideration.

> > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > 
> > The RFC shows an example of a potential "simpler" attribute using a
> > string instead of a class name. I honestly have no idea what this is
> > supposed to do or what benefit it would have over normal attributes.
> > 
> > The concept of attributes being a class name with optional arguments
> > has been proven over many years by its use in docblock annotations,
> > and if there was some deficiency in what this syntax allows it seems
> > like we would have discovered it by now.
> 
> I agree on just the string, but a closure would make 100% sense for
> a decorating feature. Javascript and Python "Attributes" work as
> decorators, i.e. they get called around the decorated function.
> 
> It is not a completely unrealistic feature to think off:
> 
> @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> function foo($message) {}

As I understand it JavaScript decorators do not use anonymous
functions for decorators like this, though. Instead you would make a
named function and apply it with `@myFunc()` before the decorated
function or class.

Presumably we could accomplish the same thing in PHP with e.g. an
`__invoke` method in the attribute class, without complicating the
attribute syntax itself.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei  wrote:

> We have updated the RFC with all (hopefully) of the feedback from
> this discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
> 
> Most notable changes are:
> - A new section with several subsections on the benefits of a closing
> delimiter / enclosing syntax.
> - A section on grouping pro/cons
> - Inclusion of @: as per Theodores request
> 
> We are looking for further feedback from the community.

Hi Benjamin and Derick,

Thank you for taking the time to further flesh out the RFC and
include the `@:` syntax option. Overall it is a lot better now.
However, I still have some concerns with several claims in the RFC
that are inaccurate or incomplete, particularly in the "Discussion
on Ending Delimiter / Enclosing Delimiters" section. [1]

The RFC intro says "we should strongly favor a syntax with closing
delimiter to keep consistency with other parts of the language". It
is then argued that "Many complex syntax constructs in PHP have an
ending delimiter", and therefore attributes should have one as well.

However, ending delimiters in PHP have little to do with how "complex"
a syntax construct is (which is a rather loose definition, anyway).
As I've pointed out before, standalone statements and declarations
generally require an end symbol, but modifiers before a declaration
do not. Attributes fall into the latter category, and therefore the
lack of an end delimiter is consistent.

The RFC responds to this counterargument with a series of four
claims, none of which is fully accurate in describing declaration
modifiers:

1. Even if we only consider keyword declaration modifiers, the claim
that "these modifier keywords all have only exactly one token that
can immediately follow them, T_WHITESPACE" is not correct. Just as
with attributes, modifier keywords can also be followed by a comment
token (#, //, or /**/):

@@Attribute// some comment
final// some comment
class Foo {...}

Strangely, the RFC only lists keywords like public and final as
declaration modifiers, and neglects to mention that type declarations
are also in this category (which I have pointed out in all my
previous responses to this argument).

Type declarations can be not only followed by whitespace and comment
tokens, but also a `T_VARIABLE` token:

function foo(Type$bar) {}

2. The RFC goes on to claim that "[declaration modifiers] are all
non-complex and are only made up of a handful ascii letters". Again,
this fails to consider type declarations, which can contain the same
non-ascii characters that attribute names can.

3. Next, the RFC says "these keywords are always on a single line".
But union type declarations can be spread across multiple lines,
and still don't have an end delimiter:

function foo(
\My\FullyQualified\ClassName
|string $param
) {...}

4. Finally, the RFC says that "visibility keywords are only boolean
or bitflags in Reflection, but Attributes are a full fledged
`ReflectionAttribute` representing their own distinct language concept."
You can probably guess where I'm going with this... Type declarations
are likewise a fully fledged `ReflectionType` representing their own
distinct language concept.

So the RFC's argument that attributes need to have a distinct ending
symbol for consistency is not convincing. The lack of an ending
delimiter is fully consistent with other declaration modifiers,
whether simple or complex.

## Benefits for IDEs and editors?

The RFC suggests a benefit of "Consistent colouring for being an end
of the attribute syntax and the keywords in between can use different
colors." I don't really understand this argument. How would an end
delimiter change the syntax highlighting provided by IDEs?

Another suggested benefit is that IDEs can "Implement regions to
open/close the grouped declaration of one or multiple attributes."
But IDEs can still do this without an end delimiter, and groups of
attributes could even be opened/closed independently by separating
them with an empty line (which should improve readability for humans
as well).

## Easier machine parsing?

The RFC shows a list of different ways that attributes with the `@@`
syntax can end, and claims "This makes programmatic token based
scanning for attribute syntax without a closing delimiter such as `@@`
unnecessarily complicated."

But I've worked with userland token stream scanners myself, and it's
not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do
that, parsing an attribute is as simple as finding any `T_ATTRIBUTE`
token followed by the name token, then checking for an optional
argument list. If there's not an argument list, that's then end of
the attribute, otherwise the end is the end of the argument list.

With the `@[]` and `#[]` syntaxes, a userland token parser is actually
*more* complex due to grouping. It not only has to do the same things
listed above, but it also has 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans  wrote:

> On Fri, 14 Aug 2020, Sara Golemon wrote:
> 
> > > Derick and Benjamin (and Sara), are these requests reasonable? If
> > > the RFC follows the discussion period rule and contains all the
> > > relevant information, I will be much more confident that it is
> > > resulting in the best long term outcome (and I think this would
> > > speak for many others on list as well).
> >
> > Honestly, the current end date is fine, because the intent of the rule
> > is met.  However, I do like that you're seeking a solution which helps
> > to put concerns to rest.
> >
> > The only part which irks me is that we have 50-some votes already cast
> > that would be thrown out and have to be redone, and that's on what is
> > already the 3rd vote on this syntax.
> >
> > I'm vote fatigued, personally.  However, we're going to have to live
> > with this syntax forever once it's out, so we should believe that we
> > believe in it.
> 
> As I've said, I have no problems with *extending* the time by the week
> and a bit that I missed. I disagree about having to stop, wipe, and
> revote. As you said, vote fatigue.

Hi Derick and Sara,

I don't think it's reasonable to simply extend the period, when the
RFC has been significantly updated to include important details that
were missing when most people cast their vote. Otherwise the vote
result does not reflect the contents of the RFC, and therefore cannot
be considered valid.

If vote fatigue is really the most important consideration here,
would this RFC have been brought to vote in the first place?

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 9:48 AM Sara Golemon  wrote:

> On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown  wrote:
> > I was very surprised that it went to vote less than six days after
> > the discussion period started, right after the weekend no less,
> > before I had a chance to submit my patch to include the @: syntax.
> 
> Yes. Derick fucked up the *letter* of the rule here. His intentions
> were good and reasonable (God knows we've discussed this agonizing
> topic for far longer than two weeks), but taking the RFC in question
> in a vacuum, it is well under two weeks. By the *intent* of the rule,
> he's fine.  This has been discussed exhaustively.
> 
> > How can the vote result be considered legitimate or binding?
> 
> Exhaustingly, I do agree. Contentious times call for careful outcomes.
> 
> > With this in mind, I'd like to respectfully make the following
> > requests:
> >
> > 1. Defer voting until the two week discussion period is complete
> > (Tuesday, August 18).
> 
> I'd say as late as the 21st.  Minimize doubt in the process.
> 
> > 2. Include a ranked voting option for @: and mention its pros and
> > cons (it is equally concise as @@ with no BC break, but is somewhat
> > harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1
> 
> Glancing at beberlei's reply, I do agree that @: is coming slightly
> out of left field. However, we're using a STV system, so might as
> well go wild with the options (within reason). HOWEVER, any option
> included is going to need the same care applied as you outline in #3
> and #4 below.

Thanks Sara. So it sounds like voting will be stopped/reset until the
21st (a week from today), to give time to update the RFC and include
the @: syntax option in the STV polls?

> > 3. Add a Backward Incompatible Changes section with examples of the
> > code that the different syntax options would break.
> 
> More information is better than less. +1
> 
> > 4. Add a Discussion section briefly summarizing the arguments that
> > have come up on list. In particular this should include:
> > a) Tyson's examples of #[] changing the meaning of code in
> >unexpected ways between PHP 7 and 8 (e.g. a parameter
> >attribute would remove the parameter when run on PHP 7).
> > b) An example of the downside of grouping, where it causes
> >unnecessary diff noise when adding or removing a second
> >attribute on its own line.
> > I'd be willing to help draft this section if the RFC authors so desire.
> 
> I say "don't ask to ask", just send some suggested text (or put up a
> gist) and let them copy it in if they want.

Okay, I drafted an initial summary of discussion arguments here: 
https://gist.github.com/theodorejb/2d39eb6e13159fc749f728900edfd0d2

> Honestly, the current end date is fine, because the intent of the rule
> is met.  However, I do like that you're seeking a solution which helps
> to put concerns to rest. The only part which irks me is that we have
> 50-some votes already cast that would be thrown out and have to be
> redone, and that's on what is already the 3rd vote on this syntax.
> I'm vote fatigued, personally.  However, we're going to have to live
> with this syntax forever once it's out, so we should believe that we
> believe in it.

Agreed. Regardless of final syntax outcome, ensuring the process isn't
rushed can provide confidence that the right decision is being made.

Kind regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 9:16 AM Benjamin Eberlei  wrote:

> On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown  wrote:
> > There's certainly been a lot of discussion in general about
> > attributes. However, there was not a reasonable opportunity to either
> > discuss the specific arguments made in this RFC (e.g. the lack of a
> > closing symbol being inconsistent), or submit patches for alternative
> > syntaxes as Derick requested when he put up the RFC for discussion.
> > 
> > I was very surprised that it went to vote less than six days after
> > the discussion period started, right after the weekend no less,
> > before I had a chance to submit my patch to include the @: syntax.
> > 
> > I'm as weary of the discussion as anyone, and would like to see
> > closure on this topic sooner rather than later. But if the voting
> > rules aren't followed, how can the vote result be considered
> > legitimate or binding?
> > 
> > If the authors sincerely want the best outcome for the language (and
> > I assume they do), what harm is there in deferring the vote until the
> > discussion period has completed, and ensuring that the RFC addresses
> > the arguments on both sides and contains all the relevant information
> > for making a decision? Otherwise many contributors (myself included)
> > just end up feeling unheard, unhappy, and unconfident that the right
> > choice is being made.
> > 
> > With this in mind, I'd like to respectfully make the following
> > requests:
> > 
> > 1. Defer voting until the two week discussion period is complete
> > (Tuesday, August 18).
> 
> What do you mean by defer exactly? Stop voting or reset the vote?
> We were thinking of extending the vote until September 1st.

Hi Benjamin,

Yes, my request is to stop/reset the vote until after the discussion
period is complete. Otherwise few people will see the updates made to
the RFC since they already voted.

> > 2. Include a ranked voting option for @: and mention its pros and
> > cons (it is equally concise as @@ with no BC break, but is somewhat
> > harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1
> 
> I am wondering where @: is suddenly coming from? It wasn't discussed
> in both shorter attributes RFC and the discussion leading to this RFC.

@: wasn't included in the Shorter Attribute Syntax RFC because I
didn't realize it was allowed to re-vote on a failed secondary poll
after less than six months. However, since we're re-voting on #[] I
think it's only fair to include @: as well - some people may prefer a
short syntax but dislike the specific look of @@. Personally I would
like to vote for @@ as my first preference and @: as my second.

> There were a few other suggestions like $() or "using attribute", but
> none of them was followed up upon. Nobody replied to my or Dericks
> message with a specific interest in actually contributing another patch,
> including @:

I hadn't replied to this part of Derick's message yet because the
voting started before I had a chance to write the patch.

> > 3. Add a Backward Incompatible Changes section with examples of the
> > code that the different syntax options would break.
> 
> Derick and I are working on this section to update the RFC later today.
> We didn't consider this relevant, because the mitigation steps for all
> of them is the same: a project wide search and replace to insert a space

Thank you for working on this. The mitigation for current usages of
@@ should be to delete the extra symbol rather than adding a space
(though I'm very doubtful that any usages of @@ even exist currently,
since extra suppression operators don't do anything useful).

The main benefit of the BC break section will be to highlight examples
of how @[] and #[] break syntax that is both valid and useful, while
@@ does not.

> > 4. Add a Discussion section briefly summarizing the arguments that
> > have come up on list. In particular this should include:
> >a) Tyson's examples of #[] changing the meaning of code in
> >   unexpected ways between PHP 7 and 8 (e.g. a parameter
> >   attribute would remove the parameter when run on PHP 7).
> 
> This is also included in the update, but ultimately is covered by the
> explanation for "Forward Compatibility" already mentioning that it
> does only work with a subset (and hence does not work for some other
> subset).

Okay, but I think examples are necessarily to illustrate which subset
of the new syntax works and what does not. It certainly wasn't clear
to me before I saw Tyson's examples.

> >b) An example of the downside of grouping, where it causes
> >   unnecessary diff noise when adding or removing a second
> &

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison  
wrote:

> > So, a week+ early, then? Surely that means the current vote null
> > and void, to be reset entirely following a proper discussion period
> > -- one without concurrent voting.
> 
> I just want to make sure I understand: there are people who think we
> haven't discussed the syntax for attributes yet?
> 
> I assume this is a serious email, but I can't fathom why anyone cares.
> We've discussed this subject soo much...

Hi Levi and internals,

There's certainly been a lot of discussion in general about
attributes. However, there was not a reasonable opportunity to either
discuss the specific arguments made in this RFC (e.g. the lack of a
closing symbol being inconsistent), or submit patches for alternative
syntaxes as Derick requested when he put up the RFC for discussion.

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

I'm as weary of the discussion as anyone, and would like to see
closure on this topic sooner rather than later. But if the voting
rules aren't followed, how can the vote result be considered
legitimate or binding?

If the authors sincerely want the best outcome for the language (and
I assume they do), what harm is there in deferring the vote until the
discussion period has completed, and ensuring that the RFC addresses
the arguments on both sides and contains all the relevant information
for making a decision? Otherwise many contributors (myself included)
just end up feeling unheard, unhappy, and unconfident that the right
choice is being made.

With this in mind, I'd like to respectfully make the following
requests:

1. Defer voting until the two week discussion period is complete
(Tuesday, August 18).

2. Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1

3. Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.

4. Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
   unexpected ways between PHP 7 and 8 (e.g. a parameter
   attribute would remove the parameter when run on PHP 7).
b) An example of the downside of grouping, where it causes
   unnecessary diff noise when adding or removing a second
   attribute on its own line.
I'd be willing to help draft this section if the RFC authors so desire.

Derick and Benjamin (and Sara), are these requests reasonable? If the
RFC follows the discussion period rule and contains all the relevant
information, I will be much more confident that it is resulting in
the best long term outcome (and I think this would speak for many
others on list as well).

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 8:47 AM Andreas Leathley  wrote:

> On 13.08.20 15:17, Theodore Brown wrote:
> > The discussion thread you're referencing did not announce an RFC. Per
> > the voting rules, a "Proposal is formally initiated by creating an
> > RFC on PHP wiki and announcing it on the list". After that there must
> > be a minimum two week discussion period before voting starts. The
> > Shorter Attribute Syntax Change RFC failed to meet this requirement.
> 
> After reading https://wiki.php.net/rfc/howto it is stated clearly there
> that an RFC has to be created and be "Under Discussion" for at least two
> weeks. So you were actually wrong that the RFC was one day early - it
> was at least 8 days early, as the RFC was created and announced on the
> 4th of August and then put to vote on the 10th of August.

Indeed, it looks like you are right. I missed that Joe withdrew his
RFC on August 2nd: https://externals.io/message/111218#111288. The
declined RFC can still be viewed via a past page revision. [1]

Apparently Derick then authored a new proposal under the same wiki
URL and moved it under discussion on August 4th, with a request that
people submit patches for other syntax alternatives to include in the
vote. [2] So the first date this RFC could be eligible for voting is
Tuesday August 18th.

Sara and Gabriel, can you confirm this is the case?

The RFC was then moved to voting on August 10th, less than a week
later, before there was a reasonable period to submit patches, and
while there was still significant ongoing and unresolved discussion.

> It also states in this document:
> 
>   * Listen to the feedback, and try to answer/resolve all questions
>   * Update your RFC to document all the issues and discussions
>   * Cover both the positive and negative arguments
> 
> Can anybody say with a straight face that this has been done in this
> case? Just one example: It still states in the RFC that the ending
> symbol is inconsistent with the language, although multiple people
> argued another viewpoint about this part with detailed explanations.
> This kind of discussion belongs in an RFC to show both sides, not
> just the one that suits the person writing the RFC.

Hear, hear. If we must vote again on the syntax, can the RFC at least
fairly present all the pros and cons for each alternative (including
details about the BC breaks), with a discussion section summarizing
the viewpoints brought up on list? This is what I attempted to do in
the original Shorter Attribute Syntax RFC. [3]

Best regards,  
Theodore

[1]: https://wiki.php.net/rfc/shorter_attribute_syntax_change?rev=1596407928
[2]: https://externals.io/message/111312#111312
[3]: https://wiki.php.net/rfc/shorter_attribute_syntax#alternative_syntax
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski 
 wrote:

> Hi Theodore,
> 
> śr., 12 sie 2020 o 18:36 Theodore Brown  napisał(a):
> > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:
> > 
> > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote:
> > >
> > > > It has just come to my attention that this RFC was rushed to vote
> > > > after less than the minimum two week period required after it was
> > > > brought up on list. Furthermore, discussion was still very active at
> > > > that time - I certainly didn't have a chance to respond to some of
> > > > the emails before voting began.
> > > >
> > > > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
> > > > vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
> > > > after the announcement. Per the voting rules:
> > >
> > > So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
> > > in trying to get the issue resolved in the minimal timeframe. The
> > > fact active discussion was ongoing makes this a questionable choice,
> > > but in my opinion, purely on a matter of time, quibbling over 30 hours
> > > is splitting hairs. Maybe compromise on adding time to the vote end
> > > period so that the total is greater than 4 weeks?
> > >
> > > > What should be done to prevent this rule from being violated?
> > >
> > > Vigilance. You're right to raise the concern. And let's wag a finger
> > > over it at least. If others agree that it's premature, we can stop
> > > the vote, but I'm not inclined to disrupt the process over such a
> > > small variance.
> > 
> > On top of violating the minimum two week discussion period, I believe
> > this RFC also breaks the rule on resurrecting failed proposals. When
> > I authored the Shorter Attribute Syntax RFC, I specifically did not
> > include a voting option for `@:`, since this syntax was declined,
> > and my understanding was that a six month waiting period is required
> > before resurrecting rejected proposals. [1]
> > 
> > But if we can vote again on `#[]` and `<<>>` after they were declined,
> > why can't we also vote again for `@:`? This syntax has the advantage
> > of being equally short as `@@` without any BC break.
> > 
> > I'm really disappointed and disillusioned with how the process has
> > been handled for this RFC. It seems like the rules are arbitrarily
> > going out the window in order to keep voting until the desired result
> > is reached.
> > 
> > What is the point of having rules if they aren't followed or enforced?
> > If anyone else is troubled by the precedent being set by this RFC,
> > please vote No on the primary vote. I'm not sure what other recourse
> > we have at this point.
> > 
> > Sincerely,
> > Theodore
> > 
> > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> 
> You hint to the fact of shorter discussion period and the fact that
> you haven't got time to respond to all discussions while if you take
> a closer look on ML [4] that is obvious that discussion in fact began
> earlier and it's 3 weeks from now and to avoid insinuation you replied
> to it [5] 3 weeks ago as well.

Hi Michał,

The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before voting starts. The
Shorter Attribute Syntax Change RFC failed to meet this requirement.

> Rejected features have nothing to do with a re-vote on a syntax
> change at least this is how I understand this. Besides you already
> mentioned this argument on ML [1] so we can argue actually if a
> re-vote on syntax change is actually resurrecting a declined
> proposal since it was not a standalone proposal which got into a
> declined section of RFC's index [2] and yet you did it again!

So you're saying that the rule on resurrecting failed proposals only
applies to primary votes, and not secondary votes? So if a secondary
vote fails it's okay to vote for it again and again until the desired
result it reached? This is not my understanding of the rules.

> You blame others for "abusing" the RFC process while you've brought
> to us an RFC with a significant ambiguity [3] which you haven't
> mention and it turned out after closing a vote. Personally I think
> that it was your huge failure to bring the previous @@ syntax change
> RFC up to the voting without checking it's correct

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:

> On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote:
> 
> > It has just come to my attention that this RFC was rushed to vote
> > after less than the minimum two week period required after it was
> > brought up on list. Furthermore, discussion was still very active at
> > that time - I certainly didn't have a chance to respond to some of
> > the emails before voting began.
> > 
> > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
> > vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
> > after the announcement. Per the voting rules:
> 
> So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
> in trying to get the issue resolved in the minimal timeframe. The
> fact active discussion was ongoing makes this a questionable choice, 
> but in my opinion, purely on a matter of time, quibbling over 30 hours
> is splitting hairs. Maybe compromise on adding time to the vote end
> period so that the total is greater than 4 weeks?
> 
> > What should be done to prevent this rule from being violated?
> 
> Vigilance. You're right to raise the concern. And let's wag a finger 
> over it at least. If others agree that it's premature, we can stop
> the vote, but I'm not inclined to disrupt the process over such a
> small variance.

On top of violating the minimum two week discussion period, I believe
this RFC also breaks the rule on resurrecting failed proposals. When
I authored the Shorter Attribute Syntax RFC, I specifically did not
include a voting option for `@:`, since this syntax was declined,
and my understanding was that a six month waiting period is required
before resurrecting rejected proposals. [1]

But if we can vote again on `#[]` and `<<>>` after they were declined,
why can't we also vote again for `@:`? This syntax has the advantage
of being equally short as `@@` without any BC break.

I'm really disappointed and disillusioned with how the process has
been handled for this RFC. It seems like the rules are arbitrarily
going out the window in order to keep voting until the desired result
is reached.

What is the point of having rules if they aren't followed or enforced? 
If anyone else is troubled by the precedent being set by this RFC, 
please vote No on the primary vote. I'm not sure what other recourse
we have at this point.

Sincerely,  
Theodore

[1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:

>I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The vote ends August 23, 24:00 UTC.

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

> a minimum of 2 weeks between when an RFC that touches the language
> is brought up on this list and when it's voted on is required. [1]

What should be done to prevent this rule from being violated?

Also, I still don't understand why this RFC has a special exemption
to the feature freeze deadline, given that the whole basis for it
(a supposed lack of consistency) is at best a subjective opinion.

Can the RMs please weigh in?

Kind regards,  
Theodore

[1]: https://wiki.php.net/RFC/voting#discussion_period
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins  wrote:

> On Tue, 11 Aug 2020 at 17:07, Theodore Brown  wrote:
> 
> > > > fact that the @@ syntax makes attributes easier to grep for.
> >
> > This can be a simple Yes or No. With @@ or @: you can type those
> > symbols followed by the attribute name to grep for it. With the other
> > syntaxes and attribute grouping, if the name isn't unique it may be
> > difficult to search for since you can't rely on a unique leading symbol.
> 
> Surely *all* of the syntaxes will be easily greppable once adopted, because
> any instances that aren't attributes will have to be fixed (other than
> those in comments and strings, which can happen with any of them).

I think you may have misunderstood my point - it's not so much about
the leading symbols but about grouping. Consider the following example:

@[
Jit,
Route("/api/posts/{id}", methods: ["GET", "HEAD"]),
]
public function show(int $id) { ... }

What will you grep for if you want to find all places where the Route attribute 
is used (but not some other class named Route)?

With the @@ syntax you can easily grep for "@@Route" to find all the
places where specifically the attribute is used:

@@Jit
@@Route("/api/posts/{id}", methods: ["GET", "HEAD"])
public function show(int $id) { ... }

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 10:39 AM Rowan Tommins  wrote:

> On Tue, 11 Aug 2020 at 16:31, Theodore Brown  wrote:
> 
> > Anyway, please do add easy typeability to the matrix
> 
> How would you measure "easy typability"? On what keyboard layout?
> Would you write "Yes" and "No", or "quite easy", or marks out of 10?

Hi Rowan,

I would suggest "Kinds of symbols used".

@@ is easier since it only uses one kind of symbol, rather than
switching between two or three symbols which are often on different
sides of the keyboard.

> > fact that the @@ syntax makes attributes easier to grep for.
> 
> The same question: how do you summarise this in a table? Complexity
> of the regex? Number of false positives in some representative code
> base?

This can be a simple Yes or No. With @@ or @: you can type those
symbols followed by the attribute name to grep for it. With the other
syntaxes and attribute grouping, if the name isn't unique it may be
difficult to search for since you can't rely on a unique leading symbol.

> As I've said before, the table would be useful if it was a re-cap of
> arguments discussed in prose elsewhere, but it is not on its own a good
> source of information for making a decision.

Generally I agree, the table is not particularly helpful in making a
decision here.

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 8:37 AM Derick Rethans  wrote:

> On Tue, 11 Aug 2020, Theodore Brown wrote:
> 
> > A second downside of @[] that doesn't appear to have been discussed
> > yet is typability. On my keyboard, it requires four different keys on
> > different sides of the keyboard, whereas @@ just requires two keys.
> 
> They're the same on a US English/US International keyboard, both 4
> presses:
> 
> For @@: Shift 2 Shift 2
> For @[]: Shift 2 [ ]
> 
> In the case of @[], an IDE likely will automatically add the
> closing ].
> 
> Additionally, on a US English/US International keybaord, Shift-2 (for @)
> is an awkward combination to type with the pinky and middle finger of
> your left hand.
> 
> On a UK English, it's the same amount, with the @ a little easier than
> on a US English one, with: left-shift @/' [ ]
> 
> So if you want to add typeability to the matrix, I can do that, but @@
> comes out worse.

How does @@ come out worse?

For @@: Shift, double-@
For @[]: Shift, @, left bracket

Even if your IDE autocompletes the closing bracket, @@ is faster to
type than @[] on common qwerty layouts. Also, it is easier to mistype
@[ as @] (I kept doing this multiple times when typing this reply).

Anyway, please do add easy typeability to the matrix, along with the
fact that the @@ syntax makes attributes easier to grep for. These
should have been in the matrix from the start, given that both were
mentioned as factors in the Shorter Attribute Syntax RFC.

When I originally wrote the Shorter Attribute Syntax RFC, I wasn't
aware that it was allowed to re-vote on failed syntax options without
waiting at least 6 months. Otherwise I would have included an option
to re-vote for the @: syntax.

Since apparently this is allowed now, can we also add @: as a voting
option? I have a patch for it here: https://github.com/theodorejb/php-src/pull/1

It seems pretty clear that the vote should be restarted anyway,
given that the RFC has already been heavily edited multiple times
after the voting started.

Kind regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 7:26 AM Chris Riley  wrote:

> On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:
> 
> > On Tue, 11 Aug 2020, Chris Riley wrote:
> >
> > > Quick question.
> > >
> > > What is the expected behaviour of:
> > >
> > > @[Bar()];
> > > class Foo {}
> >
> > That will error out in PHP 8, with:
> >
> > Parse error: syntax error, unexpected token ";" in Standard input code on
> > line 2
> 
> Is
> 
> 
> 
> on it's own an error?

Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted. However, it will remain valid to write the
following:

@ [Bar()]; // suppressed function call
@[ Bar() ] // attribute
class Foo {}

Is this still confusing? I think so. People could easily expect
that the first line is an attribute, or that attributes *should*
be followed by a semicolon since they have an ending bracket.

**This could even make it easier to sneak vulnerabilities into PHP
projects.** :\

A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys
on different sides of the keyboard, whereas @@ just requires two keys.

Thirdly, the @[] syntax with grouping removes the ability to easily
grep for attributes, which was one of the benefits of @@ mentioned in
the Shorter Attribute Syntax RFC.

Unfortunately, this new RFC fails to mention any of these issues,
thus presenting an incomplete picture of the pros and cons which
appears to be influencing the vote results against @@.

@[] has had relatively little discussion compared to the other syntax
options so far, and not all of its issues may even be known yet.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:

> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
> 
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> 
> The first vote is a vote to say that you have an opinion about attribute
> syntax. Make sure to read up on the discussion on the mailinglist if you
> haven't done so yet.

I voted "No", as the primary premise for this RFC is fundamentally flawed:

> The main concern is that @@ has no ending symbol and it's inconsistent
> with the language that it would be the only declaration or statement
> in the whole language that has no ending termination symbol.

As I pointed out in the discussion thread, this simply is not the case.
Attributes are not standalone declarations or statements, but modifiers
that always come before a declaration and add metadata to it. This
is consistent with visibility modifiers and type declarations (which
are not necessarily a single word):

# declaration modifiers do not have end/grouping symbols like this
@[MyAttr([1, 2])]
[public] function foo(@[Deprecated] [int|float] $bar) {}

# this is more consistent:

@@MyAttr([1, 2])
public function foo(@@Deprecated int|float $bar) {}

> The second vote is an STV vote.
> 
> In STV you SHOULD rank *all* choices, but don't pick the same one more
> than once, as that will invalidate your vote.
> 
> Please have a objective look at the table
> (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> don't just go by asthetics.

I find this table to be unfortunately incomplete. E.g. why doesn't it
bold the number of required characters for @@, since this is one of
its advantages? And why is "Allows Grouping" marked as an advantage
for the other three syntaxes? Grouping adds implementation complexity,
leads to unnecessary diff noise, and is rarely more concise than @@ in
real-world use cases.

I also find it concerning that the RFC doesn't have an example for each
consideration showing how one syntax addresses it better than another.
For example, the Shorter Attribute Syntax RFC showed potential nested
attributes and how @@ would support them more cleanly, but this RFC
fails to mention them anywhere.

Finally, while the table mentions that each syntax other than <<>> has
a BC break, I think it's just as important to consider the *size* of
the breaking change. #[] and @[] are larger BC breaks than @@ since
they break useful syntax:

// with #[]
#[x] code like this would break
$val = ['new value']; #['old value'];

// with @[]
$x = @[foo(), bar()]; // this code would break

Both of these are useful patterns, and I'm not convinced that breaking
them is justified. Shouldn't there be a Backward Incompatible Changes
section in the RFC with these examples?

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans  wrote:

> On Fri, 7 Aug 2020, Theodore Brown wrote:
> 
> > Even if we assume the implementation is only about 30 lines, it's
> > still extra complexity that I don't understand the benefit of. I
> > sincerely would like to know what advantage there is of grouped
> > attributes over the `@@` syntax.
> 
> It was very *specifically* voted for:
> https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes

Hi Derick,

It was specifically voted for the `<<>>` syntax, with the explicit
qualification that "This feature would be superseded by any other RFC
getting accepted that changes the syntax." This is exactly what
happened when the Shorter Attribute Syntax RFC was accepted.

> You still haven't addressed any of the deficiencies that the other
> alternatives don't have:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal

I'm not sure which deficiencies you mean, but let's briefly go
through the table in the RFC to make sure nothing has been missed:

- Number of required Characters:
- `@@` has the advantage here.

- Has End Delimiter:
- This isn't clearly a pro or a con in itself.

- Allows Grouping:
- As discussed before, `@@` has the advantage of being equally
concise without this added complexity.

- Forward Compatibility in PHP 7:
- This is at best a temporary benefit of `#[]` which will be
irrelevant in a few years, at worst a source of confusion and bugs
when code intended for PHP 8 runs on PHP 7 with different results.

- Breaks BC of valid PHP 7 code:
- All syntaxes but `<<>>` technically have a BC break. There really
should be a separate line in the table for "Breaks useful syntax",
since `#[]` and `@[]` have this deficiency, but `@@` does not.

- Used by other language:
- This is listed as an advantage for `#[]` and `<<>>`. However, the table
fails to point out that Hack is migrating away from `<<>>` to `@Attr`.
Furthermore, while `#[]` has the same start/end symbols as Rust, the rest
of the grammar/semantics vary significantly. E.g. these are valid Rust
attributes (see https://doc.rust-lang.org/reference/attributes.html):

  #[rustfmt::skip]
  struct S {}

  #[clippy::cyclomatic_complexity = "100"]
  pub fn f() {}

This is quite different from PHP's semantics, so it's not clear that
copying the same start/end symbol would really be a benefit for us.
Also note that unlike PHP, `#` does not start a comment in Rust.

- Familiar with Docblock Usage:
- `@@` has the advantage here once more.

- Tokens used:
- This isn't clearly a pro or con in itself.

- Changes the lexing of **remaining** tokens:
- This is apparently a con for `#[]`.


Ultimately I think `@@` does the best job balancing a very small BC
break with concise, familiar syntax that can cleanly support nested
attributes in the future. And since it avoids the need for attribute
grouping it also has the simplest implementation.

Kind regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei  wrote:

> On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown  wrote:
> > On Thu, Aug 6, 2020 at 12:30 PM Benas IML  > 
> > wrote:
> > 
> > > Hey Theodore,
> > >
> > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown  > 
> > > wrote:
> > >
> > > > While none of our syntax options are perfect, I believe @@ has the
> > > > best long-term tradeoffs because:
> > > >
> > > > - It doesn't break useful syntax
> > >
> > > Fair enough.
> > >
> > > > - It is equally or more concise than grouped attributes without
> > > > adding complexity to the parser/compiler
> > >
> > > Are we really going to debate that ~30 lines of code add complexity?
> > 
> > Hi Benas,
> > 
> > I don't know how many lines of code it will be, since an
> > implementation for it has never been finished. The patch currently
> > linked in the RFC does not implement it.
> 
> Curious what brings you to claim an implementation has never been
> finished when it was accepted by RFC vote?
> 
> Grouping certainly has a finished implementation, Martin and I had it
> working for the original RFC, then when we removed it for the original
> vote had a working patch and PR as part of the Amendments RFC.

Hi Benjamin,

Apologies, I didn't realize the grouped attribute implementation was
completely finished before. When it was dropped from the Attribute
Amendments pull request, a bunch of other changes still had to be
made before it was ready to merge, and I assumed that some changes
would have also been required for attribute grouping. Thank you for
the correction.

> I now ported the patch to the @[] syntax PR here: [updated link]
> https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b62ba25f950f35a16
> The zend_compile.c diff looks a bit complex, but it's really only 5
> new lines for a new for loop over the groups and all existing code
> one level deeper.
> 
> All in all the attribute grouping patch adds 26 new lines (and then
> tests) all restricted within the existing attribute parser rules and
> the functions compiling attribute code. This adds no complexity at all.

This is some new complexity, even if only a small amount right now.
My question remains about how much more added complexity it will
require later if we implement extensions like nested attributes.

> > Even if we assume the implementation is only about 30 lines, it's
> > still extra complexity that I don't understand the benefit of. I
> > sincerely would like to know what advantage there is of grouped
> > attributes over the `@@` syntax.
> > 
> > - It is equally or more verbose than `@@` in real-world use cases
> 
> You keep bringing up verbosity like our primary language design goal
> is to reduce it, PHP is the most verbose language I know. Everything
> in PHP requires more characters than in other languages. Keywords are
> usually long, variables need an extra $ in front. You have to use
> $this-> as no implicit context exists. Functions need to be prefixed
> by "array_", "str_" instead of methods on the objects.

Yes, PHP has historically been rather verbose in some ways.
Thankfully this has been gradually changing, with the short array
syntax added in 5.4, and more recently short arrow functions,
constructor property promotion, and the match expression having an
explicit goal to reduce verbosity.

> The primary design goal of a language construct in PHP is not to
> reduce verbosity.

What is the goal of the grouped attribute construct? I still haven't
received an answer about what makes it better than `@@`.

> > `@@` avoids the need for additional complexity, special cased syntax,
> > and having to modify extra lines when adding/removing separate
> > attributes.
> >
> > > > - It is conceptually closest to the docblock syntax the PHP
> > > > community is familiar with
> > >
> > > Well, if `@@` is similar to `@` (to me it isn't), we can say that
> > > `@[]` is also similar to `@`.
> > 
> > I would agree that `@[]` is more similar than `#[]` is. But arguably
> > `@@` is still the closest since docblock annotations don't require
> > being wrapped in array brackets.
> 
> But docblocks are wrapped in /** */, enclosing the whole declaration
> of them.
> 
> Both @[] and #[] are comparable with /** */ as metadata **boundary**.
> The attribute itself has no symbol prefixes or alike, it's just the
> class name.
> 
> This is a very close translation to how docblocks with userland
> doc-params work, in my opinion this makes all enclosed syntaxes much
> more in line with existing syntax, regardless of symbols used.

Aren't docblock annotations only wrapped in /** */ because they have to
be inside a comment? There is no need for this with the native
attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look
similar to docblock comment boundaries, anyway.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Thu, Aug 6, 2020 at 12:30 PM Benas IML  wrote:

> Hey Theodore,
>
> On Thu, Aug 6, 2020, 8:05 PM Theodore Brown  wrote:
> 
> > While none of our syntax options are perfect, I believe @@ has the
> > best long-term tradeoffs because:
> >
> > - It doesn't break useful syntax
> 
> Fair enough.
> 
> > - It is equally or more concise than grouped attributes without
> > adding complexity to the parser/compiler
> 
> Are we really going to debate that ~30 lines of code add complexity?

Hi Benas,

I don't know how many lines of code it will be, since an
implementation for it has never been finished. The patch currently
linked in the RFC does not implement it.

Even if we assume the implementation is only about 30 lines, it's
still extra complexity that I don't understand the benefit of. I
sincerely would like to know what advantage there is of grouped
attributes over the `@@` syntax.

- It is equally or more verbose than `@@` in real-world use cases
- Adding or removing a second attribute with grouping can require
modifying multiple lines, adding unnecessary noise to diffs:

  @@SomeAttribute("value")
  @@AnotherAttribute("value") # can be added/removed independently
  function foo() {}

  # vs.

  @[SomeAttribute("value")] # changes to:

  @[
  SomeAttribute("value"),
  AnotherAttribute("value"), # not added/removed independently
  ]
  function foo() {}

- How much more added complexity will the grouped syntax require if
we add nested attributes in the future? At the least it will have to
be special-cased in some way, either to disallow grouping for nested
attributes or to treat the grouped syntax the same as an array.

`@@` avoids the need for additional complexity, special cased syntax,
and having to modify extra lines when adding/removing separate
attributes.

> > - It is conceptually closest to the docblock syntax the PHP
> > community is familiar with
> 
> Well, if `@@` is similar to `@` (to me it isn't), we can say that
> `@[]` is also similar to `@`.

I would agree that `@[]` is more similar than `#[]` is. But arguably
`@@` is still the closest since docblock annotations don't require
being wrapped in array brackets.

> > - It is aligned with the attribute semantics of the majority of C
> > family languages
>
> In what way `#[]` or `@[]` aren't?

The majority of C family languages use `@Attr` without an extra end
symbol. This makes sense since attributes are simply metadata
modifying the declaration that follows them, similar to visibility
and type declarations.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Thu, Aug 6, 2020 at 5:24 AM Benas IML  wrote:

> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins  wrote:
> 
> > On Thu, 6 Aug 2020 at 09:12, Benas IML  wrote:
> >
> > > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
> > Do you have some basis for # only being used by "very old" codebases? As
> > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> >
> > I agree that it is probably rarer than //... and /*...*/ but let's avoid
> > unnecessary hyperbole.

> A grep search was done by someone in the mailing list in the original
> `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> to be a huge BC or not.
> 
> Just about all of the matches were either from old codebases or from
> old PHP 3-5 Metasploit exploits, which are about 5-15 years old.

Hi Benas,

You can look at the grep search here: 
https://grep.app/search?q=%23%5B[lang][0]=PHP

The first BC break in the results is from an automated pentest
framework repository which was last updated four days ago. So it
seems like this is still code that is being used.

Even the current Psalm static analysis tests use # to comment out an
array: 
https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453

Not that these individual examples are a big problem, they simply
illustrate that hash comments are still used in current projects,
sometimes in ways that the #[] attribute syntax would break.

When it comes to the @[] alternative, it's harder to grep for actual
usages, since this string is used in virtually every email validation
regex. In any case, code like @[foo(), bar()] would no longer work
without putting a space between the error suppression operator and
array (which frankly looks pretty confusing):

$x =
@ [Foo()]; // an array assignment with suppressed warnings
@[Jit()] // an attribute
function bar() {}

If there were some important language improvement that depended on
breaking these syntaxes, maybe it would be justified. But so far I
haven't seen such a justification.

> We are playing probabilities here but at the moment, no one has said
> any substantial argument why `@@` is better and thus, `@[...]` seems
> like a better option in the long term.

While none of our syntax options are perfect, I believe @@ has the best
long-term tradeoffs because:

- It doesn't break useful syntax
- It is equally or more concise than grouped attributes without adding
complexity to the parser/compiler
- It offers a clean, simple way to support nested attributes in the
future if we so desire
- It is conceptually closest to the docblock syntax the PHP community
is familiar with
- It is aligned with the attribute semantics of the majority of C
family languages

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei  wrote:

> On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans  wrote:
> > 
> > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > > Syntax Change RFC to reflect that process:
> > >
> > > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> > >
> > > Patches and comments welcome.
> > 
> > Hi Derick,
> > 
> > I don't agree with the main argument put forward in this RFC:
> > 
> > > The main concern is that @@ has no ending symbol and it's
> > > inconsistent with the language that it would be the only
> > > declaration or statement in the whole language that has no ending
> > > termination symbol.
> > 
> > Attributes are not a standalone statement or declaration; they are
> > metadata *on* a declaration. They cannot stand alone, but always
> > modify the following declaration, just as public and static modify
> > a method, or a type declaration modifies a parameter or property.
> > 
> > Modifying declarations (e.g. for visibility and type) do not have an
> > ending symbol. For example, we don't write something like:
> > 
> > [public] function foo([int] $bar) {}
> > 
> > With the @@ syntax attributes are treated consistently with type and
> > visibility declarations:
> > 
> > @@Jit
> > public function foo(@@Deprecated int $bar) {}
> > 
> > So there is nothing inconsistent about not having a termination
> > symbol - this is in harmony with visibility and type declarations in
> > PHP, as well as the attribute syntax used by a majority of C family
> > languages. [1]
>
> Attributes are potentially way more complex than a visibility keyword.
> As such it is a reasonable requirement to say they should have a
> unified ending symbol, or more broadly speaking that attributes should
> be enclosed by syntax.

Hi Benjamin,

Yes, attributes that take arguments are more complex than a
visibility keyword. Union types can also be more complex.
Nevertheless it is consistent for these declaration modifiers to
not have an ending symbol.

> It looks nice for a simple attribute like @@Jit, or for a one without
> arguments like the used @@Deprecated, but as soon as there are more
> than one, and they each get arguments, enclosing them has its own
> benefits over them just standing for themselves.

Can you clarify what benefits there are to enclosing them as soon as
there is more than one attribute with arguments? From my perspective
this just adds needless complexity without being more concise than
the @@ syntax.

To me it also looks somewhat strange and less readable to require
both a closing parenthesis and a closing bracket when an attribute
has arguments:

#[MyAttr(
"some value",
[1, 2, 3],
namedArg: true,
)]

# vs.

@@MyAttr(
"some value",
[1, 2, 3],
namedArg: true,
)

> > When it comes to supporting attribute grouping, I actually consider
> > this a downside of the #[], @[], and <<>> syntaxes. It complicates
> > the internal implementation, and makes it so developers have to
> > choose between two different syntaxes when adding more than one
> > attribute. In real-world use cases the @@ syntax is just as or even
> > more concise without the extra parser/compiler complexity:
> > 
> > #[Attr1, Attr2] # 15 chars
> > 
> > @@Attr1 @@Attr2 # 15 chars
> > 
> > # 4 lines, 53 chars not counting whitespace
> > @[
> > AttrWithParam("foobar"),
> > SomeOtherAttr("fizzbuzz"),
> > ]
> > 
> > # 2 lines, 52 chars
> > @@AttrWithParam("foobar")
> > @@SomeOtherAttr("fizzbuzz")
> > 
> > I agree that we want the best syntax, not necessarily the best
> > **looking** syntax. I still believe that the @@ syntax offers the best
> > balance here. It's familiar, concise without additional complexity,
> > and doesn't break useful syntax the way @[] and #[] do.
> 
> Yes, we have been doing this for 20 years, adding annotations enclosed
> with /** and */ with each enclosing on its own line for the most part.
> We even added stars in front of every inbetween line.
> 
> we are stepping into unchartered territory here with @@ by our
> standards as PHP community. Using "C familiy" as an argument that
> they made @ work does not mean much, because the language itself is
> just the "interface" to the implementation, each C family language
> probably has vastly

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans  wrote:

> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
> 
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
> 
> Patches and comments welcome.

Hi Derick,

I don't agree with the main argument put forward in this RFC:

> The main concern is that @@ has no ending symbol and it's
> inconsistent with the language that it would be the only
> declaration or statement in the whole language that has no ending
> termination symbol.

Attributes are not a standalone statement or declaration; they are
metadata *on* a declaration. They cannot stand alone, but always
modify the following declaration, just as public and static modify
a method, or a type declaration modifies a parameter or property.

Modifying declarations (e.g. for visibility and type) do not have an
ending symbol. For example, we don't write something like:

[public] function foo([int] $bar) {}

With the @@ syntax attributes a treated consistently with type and
visibility declarations:

@@Jit
public function foo(@@Deprecated int $bar) {}

So there is nothing inconsistent about not having a termination
symbol - this is in harmony with visibility and type declarations in
PHP, as well as the attribute syntax used by a majority of C family
languages. [1]

When it comes to supporting attribute grouping, I actually consider
this a downside of the #[], @[], and <<>> syntaxes. It complicates
the internal implementation, and makes it so developers have to
choose between two different syntaxes when adding more than one
attribute. In real-world use cases the @@ syntax is just as or even
more concise without the extra parser/compiler complexity:

#[Attr1, Attr2] # 15 chars

@@Attr1 @@Attr2 # 15 chars

# 4 lines, 53 chars not counting whitespace
@[
AttrWithParam("foobar"),
SomeOtherAttr("fizzbuzz"),
]

# 2 lines, 52 chars
@@AttrWithParam("foobar")
@@SomeOtherAttr("fizzbuzz")

I agree that we want the best syntax, not necessarily the best
**looking** syntax. I still believe that the @@ syntax offers the best
balance here. It's familiar, concise without additional complexity,
and doesn't break useful syntax the way @[] and #[] do.

Kind regards,  
Theodore

[1]: 
https://wiki.php.net/rfc/shorter_attribute_syntax#comparison_to_other_languages
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Sun, Aug 2, 2020 at 4:40 PM Dan Ackroyd  wrote:

> Theodore Brown  wrote:
> >
> > The Shorter Attribute Syntax RFC explicitly mentioned that the @@
> > syntax would supersede the grouped attributes proposal: [1]
> 
> From the RFC:
> >
> > # Unaffected Functionality
> > ...it will supersede the syntax for grouped attributes.
> 
> I missed that change at least in part because it's listed under
> "unaffected functionality".
> 
> Even reading it now, it's not obvious that "superseded" means "grouped
> attributes won't be supported".

Hi Dan,

I'm not sure it can really be called a change, since at the time the
Shorter Attribute Syntax RFC went to vote the Attribute Amendments
RFC had not yet been accepted (and it certainly wasn't clear whether
the grouped attribute proposal would pass).

Anyway, the whole point of the grouped attribute syntax was to
alleviate some of the verbosity of the << and >> tokens when adding
multiple attributes. The @@ syntax supersedes, or replaces grouped
attributes since in real-world use cases it is even less verbose than
the grouped attribute proposal, [1] while avoiding its additional
implementation complexity.

Kind regards,  
Theodore

[1]: https://externals.io/message/110355#110414
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Sun, Aug 2, 2020 at 10:06 AM Derick Rethans  wrote:

> On Wed, 29 Jul 2020, Benjamin Eberlei wrote:
> 
> > Personally I favor #[] myself, but there has been a vote with a
> > substantial participation choosing @@. Overturning this democratic
> > outcome should require **significant** technical arguments, otherwise
> > this RFC would provide problematic precedent for any RFC to be
> > overturned by arbitrary revoting.
> >
> > The arguments the RFC brings forward don't convince me that we should
> > pick #[] over @@.
> 
> However, one other thing just came to light where the "Shorter Syntax"
> RFC was unclear about: no longer supporting grouping.
> 
> Changing the accepted << .. >> syntax breaks something that
> was accepted through "Attribute Amendments": grouping, as per
> https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes
> 
> The switch to @@ does now not allow for this, but we haven't spefically
> voted on we wanted to get rid of grouping. The Shorter Syntax RFC does
> talk about it in "Verbosity"
> (https://wiki.php.net/rfc/shorter_attribute_syntax#verbosity), but
> that's not a technical reason, just opinion about readability.

Hi Dereck,

The Shorter Attribute Syntax RFC explicitly mentioned that the @@
syntax would supersede the grouped attributes proposal: [1]

> this proposal does not conflict with the Attribute Amendments RFC,
> with the exception that if the @@ syntax is accepted, it will
> supersede the syntax for grouped attributes.

This was also documented in the Attribute Amendments RFC itself: [2]

> This feature would be superseded by any other RFC getting accepted
> that changes the syntax.

I agree with Benjamin that the democratic outcome of the vote between
<<>>, @@, and #[] should not be overturned unless there is a serious
technical problem with the implementation, otherwise we set precedent
for someone to overturn any RFC by arbitrarily re-voting until they
get the result they want.

Best regards,  
Theodore

[1]: https://wiki.php.net/rfc/shorter_attribute_syntax#unaffected_functionality
[2]: 
https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, July 28, 2020 at 6:09 PM Mark Randall  wrote:

> On 28/07/2020 22:55, Theodore Brown wrote:
> > I appreciate the examples. I think there are good reasons not to
> > implement these kind of extensions, at least in this form. I'll reply
> > to each example below.
> 
> 
> The problem is your argument comes from a position of... because you
> don't like those examples, we shouldn't make accomodation for them or
> anything like them in future.
> 
> Adopting such extensions is a matter for a future RFC, and not for
> preemptively throwing a spanner in the works.

Hi Mark,

Future RFCs are as free as they've always been to propose new
additions and extensions. Do you think we need to choose a more
verbose syntax for every new feature in PHP just to make sure it
accommodates keyword flags on the off-chance we may want to add them
later?

E.g. should we re-vote on the named arguments RFC now and replace the
syntax with something designed around adding flags to each argument
(e.g. so that function calls could support both an old and new
parameter names and be compatible with multiple library versions)?

There's good reason to believe that such added complexity is not
the best approach, and is very unlikely to be accepted. Preemptively
implementing a more verbose syntax with a larger BC break, on the
basis of hypothetical extensions which haven't been needed in any
other language isn't a good approach to language design, in my view.

Anyway, apart from the fact that feature freeze is less than a week
away, it seems like voting again to use #[] instead of @@ would
violate the voting rules. [1] It hasn't been six months since the
last vote, and this proposal is identical to the one declined in the
previous RFC.

Best regards,  
Theodore

[1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, July 28, 2020 at 2:38 PM Mark Randall  wrote:

> On 28/07/2020 18:57, Theodore Brown wrote:
> >> Having a closing ] makes it easier to extend Attributes with more syntax
> >
> > This might be a good argument if there were actually a need to extend
> > attributes with more syntax. What other languages have found a need for
> > this? Even Rust doesn't allow additional syntax inside the brackets.
> 
> Just because they haven't, does not mean we won't. Unless there's a good
> reason to do otherwise, we should provide for future flexibility where
> possible.
> 
> I previously provided examples of ways in which we might want to extend
> the syntax.

Hi Mark,

I appreciate the examples. I think there are good reasons not to
implement these kind of extensions, at least in this form. I'll reply
to each example below.

> Most things in PHP allow some level of scope restriction, such as
> private or protected. One day we may want to extend annotations to
> include such a feature, such as a protected annotation that can only be
> accessed by the class itself or its descendants.
> 
> #[protected MyAttribute(xyz)]

Given that attributes are metadata, restricting their scope seems
rather pointless, and probably would only encourage their (mis)use
for things they aren't the right solution for. Isn't the whole point
of an attribute to be read by something outside the class? If the
metadata is only for the class itself, class constants with
appropriate visibility can be used instead.

> Attributes are not validated when they are encountered, this may be
> something that we wish to allow attributes to opt-in to in future.
> 
> #[checked MyAttribute(xyz])

I hope if we allow opting into such a feature it won't have to be so
verbose and won't require making checked a new reserved keyword. I
suppose the same thing could be accomplished with a distinct token,
for example:

@@!MyAttribute(xyz)

> In future we might want to offer APIs that return an array of all of the
> instances (moving the creation up from newInstance) and then tighten up
> the behvaiour for classes which do not exist (because they might belong
> to an optional package, such as debugging or code analysis). This might
> come in the form of something like:
> 
> #[optional MyAttribute(xyz)]

Existing attributes are already optional, though, so it's not clear
what value this would add. If we want some attributes to not be
optional, we could add a new syntax for checked attributes like the
previous example.

> Some of these might happen, none of these might happen, something
> completely different might happen.
> 
> What is clear is we've got to support Attributes for 20, 30 years, and
> we should leave the door open for easier and cleaner syntax additions if
> there's no compelling reason not to.

I'm not convinced this approach of additional keywords before an
attribute is the easiest or cleanest way to implement additions. It
seems like it could lead to more BC breaks and unnecessary verbosity
if it encourages adding new keywords. And as you point out, whether
any such additions happen is completely hypothetical right now.

In the present what we do know is that #[] is a bigger BC break than
@@, and that other languages haven't had a need for such syntax
additions in the many years that attributes have been around.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, July 28, 2020 at 9:46 AM Joe Ferguson  wrote:

> Hello Internals,
> 
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Shorter
> Attribute Syntax.
> 
> An important part of the research that went into this proposal demonstrates
> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
> (and similar tools) and shows how the alternative "#[]" syntax is more
> friendly for these tools.
> 
> You can find the RFC
> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
> answer any questions as best I can.

Hi Joe,

>From the perspective of looks alone I don't care much one way or the
other between @@ and #[]. However, I don't find the arguments for #[]
in this RFC very compelling, and it ignores some of the other downsides
of #[] compared to @@ that should be highlighted. Let's go through the
arguments from the RFC:

> It [@@] currently causes a parser conflict

This isn't true now that namespaced names are treated as tokens. The
@@ implementation has been merged into php-src and there is no parser
conflict.

> Various luminaires [sic] consider @@ a joke

Who does this refer to? A random Reddit user?

> Feedback to Derick's tweet 
> (https://twitter.com/derickr/status/1285912223639130114)
> were [sic] overwhelmingly positive

Are you sure? I took a look at the thread and it seems like the
responses were pretty mixed. Some people expressed support for #[],
but almost as many were happier with the @@ syntax. If anything the
majority of responses were neutral or expressing dislike for all the
syntax options.

> It has the distinct possibility to cause further parsing issues

Like what? How is it any more likely to cause parsing issues than the
@ syntax used by the majority of other C family languages?

> Having a closing ] makes it easier to extend Attributes with more syntax

This might be a good argument if there were actually a need to extend
attributes with more syntax. What other languages have found a need for
this? Even Rust doesn't allow additional syntax inside the brackets.

> There is no “end symbol” to make finding occurrences easier,
> including by reading or using regular expressions.

Can you provide an example? When reading code I personally don't find
the ending bracket very helpful - my brain tends to parse it as the
end of an array, not the end of an attribute. Even when using a regex
to search code, the ending bracket doesn't seem very helpful since
arrays can also be passed as attribute arguments. For example, to
match this attribute the regex for @@ is actually simpler than the
one for #[]:

```php
# regex: /@@\w+\(.+\)/
@@Attr([1, 2])

# vs.

# regex: /#\[\w+\(.+\)\]/
#[Attr([1, 2])]
```

> A syntax with a closing demarcation is much easier to back fill with
> tools such as PHPCS.

I'm not sure I understand this. What does it mean to "back fill" a
syntax with PHPCS, and what does a closing demarcation have to do with
it? As a user, I'd expect to have to update PHPCS to work with PHP 8
code - doesn't it have to be updated anyway to correctly support the
syntax for named arguments, union types, the nullsafe operator, match
expression, etc.?

And from a perspective of compatibility with existing tools, couldn't
@@ be considered superior since people can use it in code examples
on a blog without the syntax highlighter treating it as a comment?

> It is a syntax no other language uses.

Rust chose to use #[] even though it wasn't used by any other language.
Does that make it a bad fit for Rust? No. But just because Rust uses
a syntax also doesn't mean it's a good fit for PHP.

@@ fits well with PHP since there is virtually no BC break, and the
syntax is close to the @annotation syntax currently used in docblocks,
so it's easily recognizable for what it is. On the other hand, #[]
would be a larger BC break and can easily be confused for a comment.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Theodore Brown]

On Thu, July 23 2020 at 1:26 AM Mark Randall  wrote:

> On 23/07/2020 02:00, Sara Golemon wrote:
> > Regards the vote; I don't believe that @@ has been proven unworkable,
> > however if I'm wrong about that, then the second choice selection from the
> > last vote would obviously take precedence.
>
> I don't believe the concern is that we have something unworkable sitting
> in front of us right now, after all if that were the case we would not
> be needing to have this conversation as the RFC would already have been
> rendered void.
> 
> What we do have, is a deep sense of unease that we collectively made the
> wrong decision, based on, in part, incomplete information.
> 
> While the initial block to @@ has been remedied by a larger
> language-level change, that the problem existed at all provided a clear
> example of the widely unforeseen challenges associated with the @@
> syntax and its lack of closing tags, and focused renewed attention on
> long-term consequences which where perhaps not given enough
> consideration during the vote.
> 
> There has been one occurrence already, there will likely be more in the
> future. But what specifically will they be and how severe? We likely
> will not know until they happen.

Hi Mark,

I don't agree that there "will likely be more in the future". When I
asked Nikita if he could think of any example that would end up being
a problem, the only one he listed was a infinite parser lookahead
requirement if a) attributes were allowed on statements and b)
generics were implemented with curly braces instead of angle brackets.

He noted that "it's unlikely we'd actually do that" and ended his
email by saying "it is more likely than not, that we will not
encounter any issues of that nature." [1]

The @ attribute syntax has been used in other C family languages for
years, and to my knowledge hasn't caused any problems in practice.

It is actually the <<>> variant that is more likely to back us into a
corner when it comes to future syntax like nested attributes (the RFC
authors considered it to cross a line of unacceptable ugliness,
and the alternative `new Attribute` syntax has technical problems).
This may be one reason Hack is moving away from it to @.

> But what we can say with reasonable confidence is we have an option
> on the table that is technically superior

I don't agree that #[] is technically superior. The implementation is
virtually identical. The main practical difference is that hash
comments could no longer start with a [ character, which would be
surprising behavior and a larger BC break (there's definitely code in
the wild using this right now).

If you have a concrete example of syntax that is *likely* to cause a
problem with @@, please share it. From my perspective, @@ is closest
to the syntax used by the majority of C family languages for
attributes, and thus is *least likely* to present future challenges.

Best regards,  
Theodore

[1]: https://externals.io/message/110568#111053
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Theodore Brown]

On Wed, July 22 2020 at 7:00 AM Derick Rethans  wrote:

> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
> 
> - There are lots of grumbles, both on here, room 11, as well as in the
>   wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
> 
> Please, let's do the sensible and use the Rusty #[...] syntax.

Hi Derick,

Most of the comments in that Reddit thread appear to be positive or
neutral, and in the earlier community poll, the @@ syntax received by
far the most votes 
(https://www.reddit.com/r/PHP/comments/h06bra/community_poll_attribute_syntax/).
So while some in the community may prefer a different syntax, this
doesn't seem to reflect the majority.

If @@ actually has parsing issues, then I would agree that we need to
pick another syntax. But there aren't any issues following Nikita's
RFC to treat namespaced names as tokens. Please check out the
implementation and let me know if you find any problems:
https://github.com/php/php-src/pull/5796.

While most would like to have a single @ character for attributes,
since this isn't possible @@ is the closest alternative, and it
shouldn't present any parsing issues that wouldn't also affect a
single @ character. Of course it will always be possible to think of
theoretical ambiguities with unconventional future syntax, but in
practice this hasn't been an issue for the many other languages using @.

One of the benefits of @@ is actually making it easier to find
occurrences. <<>> is problematic here since these characters also
occur in heredocs/nowdocs and bit shifts. And the ending bracket of
#[] is also used for arrays, so it's not clear that this is very
helpful, either.

The benefit of #[] being exactly the same as another language was
considered in the Shorter Attribute Syntax RFC, but apparently most
voters didn't feel that this outweighed the downsides of a larger BC
break, extra verbosity, and possible confusion with comments.

If there isn't an actual technical problem with the implementation, I
don't think it would be appropriate to hold another vote, or discard
the first preference vote of all those who preferred the @@ syntax.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Theodore Brown]

On Thu, July 16 2020 at 3:04 AM Nikita Popov  wrote:

> While I don't think anyone had plans to mix whitespace, this is
> indicative of a larger issue. While I'm one of the people who voted
> for @@ as my first choice before, I wouldn't do so now (even with
> this RFC accepted). This issue made me realize that there is more at
> stake here than just "which syntax is prettier?" and choices that
> have a "closing tag" are technically more favorable, especially if
> we consider future extensions of the attribute system that may
> introduce additional ambiguities (e.g., Rust allows placing
> attributes pretty much everywhere in code -- how sure are we that
> there will be no unanticipated ambiguities?)

Hi Nikita,

Can you think of an example that would cause an ambiguity even when
namespaced names are treated as tokens? As I understand it, there
can't be an ambiguity, since there would always be an attribute token
followed by a class name token. It should be possible to put this
anywhere it makes sense without ambiguities.

Other languages like Java allow attributes/annotations in more places
than PHP (e.g. on variables) and the @ syntax doesn't prevent this.

Theodore

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

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

[Theodore Brown]

On Tue, July 14 2020 at 10:10 AM Levi Morrison wrote:

> On Mon, Jul 13, 2020 at 11:52 AM Marcio Almada  wrote:
> > > I'd like to change the default mode of assertion failures to throw.
> > > The current default is to warn. In my opinion this is a bad strategy:
> > > the engine asserted that something that is expected to be true is not,
> > > so executing further is a bad idea. This leaves throwing or bailing
> > > out. I think throwing an exception is better than bailing out, so
> > > that's what I propose.
> >
> > Couldn't agree more, but I always assumed this BC break could be
> > too big before. Did you make any research on the impact already?
> >
> > Otherwise +1
> 
> Nikita put together a search of top packagist repositories to look for assert:
> https://gist.github.com/nikic/8311ee63c72573d514217456bf2df552
> 
> We can't generally know what their ini settings are, though.
> 
> In my opinion this change is worth any backwards compatibility break
> as we are choosing the worst setting except for ignoring them
> altogether, and can be changed back to the previous value using an
> existing ini setting; we just need to put a note in the migrating
> guide.

Big +1 on changing the default to throw. The current default of only
producing a warning is surprising and can result in code continuing
to execute in a state the developer intended to prevent.

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

Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void

[Theodore Brown]

On Thu, July 2, 2020 at 4:12 PM Benas IML  wrote:

> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
> 
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void

Hi Benas,

Thanks for your work on this. I'm in favor of deprecating the ability
to return values from constructors and destructors to align their
behavior with the documentation and how most other languages work.

Unfortunately, the RFC doesn't provide an option to vote just for
this. Instead it only offers combining the deprecation with a new
option for developers to choose whether constructors and destructors
are explicitly typed as void.

But what will be the benefit of typing constructors/destructors as
void when this is the only allowed type, and after the deprecation
adding the type won't change anything anyway? It will lead to a
situation where some projects require the explicit type, others
require not having an explicit type, and the rest have a mishmash of
the two. This will lead to further bikeshedding in projects and
unnecessary code changes.

Allowing an explicit void type on constructors is also at variance
with other languages. For example, TypeScript does not allow
constructor return type declarations. [1] Nor does C# [2], nor does
Java. [3] Likewise, C++ constructors do not allow an explicit return
type [4], nor do initializers in Swift [5] and Kotlin [6].

For these two reasons, I voted no on this RFC. I think it would be
fine to deprecate the ability to return values from constructors/
destructors, though, and this could happen in PHP 8.1 if there isn't
time for it to land in PHP 8.0.

Best regards,  
Theodore

[1]: 
https://www.typescriptlang.org/play/?target=7=5#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A
[2]: 
https://www.c-sharpcorner.com/article/different-types-of-constructor-in-c-sharp/
[3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html
[4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019
[5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html
[6]: https://kotlinlang.org/docs/reference/classes.html#constructors

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

Re: [PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Thu, July 2 2020 at 8:14 AM Nikita Popov  wrote:

> On Thu, Jul 2, 2020 at 2:13 AM Theodore Brown  wrote:
> > On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:
> > 
> > > I've opened voting on the Shorter Attribute Syntax RFC:
> > > https://wiki.php.net/rfc/shorter_attribute_syntax
> > >
> > > Since all RFCs require a primary vote with a 2/3 majority, there is
> > > a main vote to approve the secondary ranked-choice vote.
> > >
> > > For the ranked-choice poll, fill in your first through third syntax
> > > choices, making sure not to select the same syntax more than
> > > once. You don't have to vote for all three options, but please
> > > don't leave gaps.
> > >
> > > Voting will end in two weeks, on 2020-07-01.
> > 
> > Hi internals,
> > 
> > The Shorter Attribute Syntax RFC vote is now closed. The primary poll
> > for re-voting on attribute syntax was approved with 50 in favor and 8
> > opposed.
> > 
> > For the secondary ranked-choice poll there are 61 valid ballots. Since
> > only one syntax can be elected, the quota is floor(61 / 2) + 1 = 31.
> > 
> > Note: one ballot wasn't counted since it selected the same syntax
> > more than once. However, this does not change the vote outcome.
> > 
> > In the first round the tally is as follows:
> > 
> > @@: 34 votes  
> > #[]: 21 votes  
> > <<>>: 6 votes  
> > 
> > So @@ reaches the quota and has been elected as the final attribute
> > syntax for PHP 8.
> > 
> > Thank you to everyone who voted!
>
>
> Hi Theodore,
> 
> Unfortunately, the RFC failed to mention a small, but important detail:
> The @@ syntax is ambiguous, as pointed out by Martin Schröder:
>
> function (@@X \ Y $param) { }
> 
> Taking into account that PHP allows whitespace between namespace
> separators, this can either be interpreted as an attribute "X\Y" on an
> untyped parameter, or as an attribute "X" on a "\Y" typed parameter.
> 
> The RFC implementation solves this by treating @@ and the following name
> as a single token that does not permit whitespace. As such, it will be
> interpreted as "X" with an "\Y" typed parameter.
> 
> Now, if this had been explicitly mentioned in the RFC, we could have made
> an explicit decision to accept this language inconsistency: To forbid
> whitespace in namespaced names for attributes only, unlike all other
> places in PHP accepting namespaced names. However, it was not mentioned
> in the RFC, and apart from the authors of the proposal, I don't think
> anyone was aware of this ambiguity.
>
> Fortunately, there is still a way to resolve this issue in a consistent
> manner: Change the handling of namespaced names in PHP in general. This
> is exactly what is proposed in 
> https://wiki.php.net/rfc/namespaced_names_as_token.
> If that proposal is accepted, then the ambiguity would disappear (and
> the above example would become a parse error).
> 
> My plan would be to change the 
> https://wiki.php.net/rfc/namespaced_names_as_token
> proposal to either only deal with the handling of namespaced names
> (i.e. as a single, whitespace-free token), or at least separate the
> other reserved keyword related changes into a separate vote.
> 
> If that proposal passes, then there should be no issue with adopting the
> @@ syntax for attributes (unless there are other problems I'm not aware
> of?) If it does not pass, then we'll have to discuss what we want to do
> here.

Hi Nikita,

Thanks for bringing this up. The original Attributes v2 RFC mentioned
that the shorter @: syntax "does not permit whitespace in attribute
names to allow detecting the ending of the declaration", but when I
wrote the new RFC I didn't think to mention that this applies to @@
as well (the implementation is almost exactly the same).

It certainly could be considered inconsistent that whitespace is
allowed in most namespaced names, but not attributes. On the other
hand, since attributes are new syntax anyway it's arguably okay for
them to have stricter semantics.

But I agree that the ideal solution would be to change the handling of
namespaced names in general, per your 
https://wiki.php.net/rfc/namespaced_names_as_token
RFC. This would also have the benefit of minimizing the impact of
reserving new keywords.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:

> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
> 
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondary ranked-choice vote.
> 
> For the ranked-choice poll, fill in your first through third syntax
> choices, making sure not to select the same syntax more than
> once. You don't have to vote for all three options, but please
> don't leave gaps.
> 
> Voting will end in two weeks, on 2020-07-01.

Hi internals,

The Shorter Attribute Syntax RFC vote is now closed. The primary poll
for re-voting on attribute syntax was approved with 50 in favor and 8
opposed.

For the secondary ranked-choice poll there are 61 valid ballots. Since
only one syntax can be elected, the quota is floor(61 / 2) + 1 = 31.

Note: one ballot wasn't counted since it selected the same syntax
more than once. However, this does not change the vote outcome.

In the first round the tally is as follows:

@@: 34 votes
#[]: 21 votes
<<>>: 6 votes

So @@ reaches the quota and has been elected as the final attribute
syntax for PHP 8.

Thank you to everyone who voted!

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

Re: [PHP-DEV] Re: [RFC] Named arguments

[Theodore Brown]

On Mon, June 29, 2020 at 10:13 AM Nikita Popov  wrote:

> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov  wrote:
> 
> > As we're moving in on feature freeze, I plan to move this proposal forward
> > soonishly.
> >
> > I have update the RFC to drop the syntax as an open question (I haven't
> > seen much opposition to the use of ":"), and to describe the possible
> > alternative LSP behavior at
> > https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance.
> >
> > While writing this down and implementing it, I found that this has more
> > odd edge-cases than anticipated. Overall, I'm not sold that this approach
> > is worth it. It sounds nice on paper, but I strongly suspect that it solves
> > a problem that does not existing in practice, and will force us to keep
> > this patch-over mechanism indefinitely, while the real solution would have
> > been to fix the limited amount of code that is in the intersection of
> > "renames parameters" and "is actually invoked with named arguments".
> 
> Just as another reminder: I plan to put this to voting by the end of the
> week.
> 
> I've also updated the RFC to make the LSP behavior a secondary vote. I'm
> not convinced this is a good idea myself, but some others seemed to prefer
> this approach.

Hi Nikita,

Thanks for moving this forward. Currently I work with a lot of value
objects which are constructed from an associative array (requiring
lots of manual validation), and named arguments will make it feasible
to migrate most of these to simple typed parameters that can be
statically analyzed instead. For me at least this will be one of the
nicest features in PHP 8.

I'm also looking forward to the potential future shorthand syntax
for matching parameter and variable names, which could also reduce
boilerplate in array construction and destructuring.

I'll probably vote No on the secondary "Automagically allow using
parent parameter names?" vote. This is a feature that could always be
added later without a BC break, but if it's added now it would be
hard to remove if the extra complexity causes problems. For these
rare cases it's probably better to update the parameter names to
match or stick with normal sequential arguments.

Best regards,
Theodore

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

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Thu, June 18, 2020 at 7:40 AM Aleksander Machniak  wrote:

> If @@ wins, will a sequence of 3-or-more @ characters forbidden?
> It is not stated in the RFC. I.e. what happens if you write:
>
> @@@ExampleAttribute()
> class Foo
> {
> }
>
> @@@some_function();

Hi Aleksander,

Yes, those examples would be syntax errors if the `@@` proposal is
accepted.

Regards,
Theodore


From: Aleksander Machniak 
Sent: Thursday, June 18, 2020 7:40 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

On 18.06.2020 01:59, Theodore Brown wrote:
> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not stated in the RFC. I.e. what happens if you write:

@@@ExampleAttribute()
class Foo
{
}

@@@some_function();

--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

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

Re: [PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Thu, June 18, 2020 at 8:40 AM Mark Randall wrote:

> On 18/06/2020 00:59, Theodore Brown wrote:
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> 
> I'd be wary of @@ simply because if we do add validation to them,
> we would likely want to use the suppression operator to indicate
> that a class might be omitted (such as if an optional package is
> not installed).
> 
> At which point we're left with @@@ and that's getting into silly-land.

Hi Mark,

Attributes were already designed to be optional, though, so there's
no need to suppress anything. Attribute validation occurs when you
call `ReflectionAttribute::newInstance()`.

Or are you suggesting that we reverse the way this works, and always
validate attributes unless a suppression operator is used? I'm not
convinced this is a good idea - it would require adding a suppression
operator for all the use cases where attribute information is
collected without an attribute class, which changes something that
should be an internal implementation detail to require different
syntax for end-users of a library. Also, it could be confusing if the
suppression operator only prevents autoloading, but doesn't suppress
other warnings. And if it does suppress other warnings, that would
probably not be what developers want in most cases.

Lastly, in my personal opinion combining the suppression operator
with attribute declarations looks like even worse symbol soup with
with the other syntax options. :)

Best regards,
Theodore

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

[PHP-DEV] VCS Account Request: theodorejb

[Theodore Brown]

I would like the ability to vote on PHP RFCs.

I worked on two successful RFCs for PHP 7.4 (numeric literal separators and the 
curly brace array/string access deprecation), and have also contributed other 
bug fixes and improvements to core.

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

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Wed, June 17, 2020 at 7:23 PM Ben Ramsey wrote:

> > On Jun 17, 2020, at 18:59, Theodore Brown  wrote:
> > 
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> > 
> > Since all RFCs require a primary vote with a 2/3 majority, there is
> > a main vote to approve the secondary ranked-choice vote.
> 
> I don’t understand this question:
> 
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
> 
> Is this a vote to see if we want to re-vote on the attribute syntax? I
> think this is worded awkwardly, and I’m not sure what the outcome of a
> yes or not vote means for this question.

Hi Ben,

I apologize if the wording is a bit awkward. The primary vote is to
formally approve holding the secondary ranked-choice vote, since all
RFCs require a primary vote with 2/3 majority. If the primary vote
doesn't reach a 2/3 majority, then the results of the secondary vote
won't be binding.

I haven't heard from anyone who is against holding the ranked-choice
vote, but based on discussion with the RMs we felt it was best to
include this primary vote to make sure the RFC doesn't deviate from
the rules.

> If I vote “no,” should I still vote in the secondary vote, or is voting
> “no” effectively the same as choosing `<<>>` for all three choices in
> the secondary vote?
> 
> Or, if I vote “no,” does that mean anything I select for the secondary
> vote is thrown out?

No, voting "no" on the primary poll won't add or remove any votes from
the secondary poll. If the `<<>>` syntax is your first choice, you
should mark it as such in the secondary poll.

Best regards,
Theodore

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

[PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

Hi internals,

I've opened voting on the Shorter Attribute Syntax RFC:
https://wiki.php.net/rfc/shorter_attribute_syntax

Since all RFCs require a primary vote with a 2/3 majority, there is
a main vote to approve the secondary ranked-choice vote.

For the ranked-choice poll, fill in your first through third syntax
choices, making sure not to select the same syntax more than
once. You don't have to vote for all three options, but please
don't leave gaps.

Voting will end in two weeks, on 2020-07-01.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Shorter attribute syntax

[Theodore Brown]

On Wed, June 3, 2020 at 6:54 PM Theodore Brown wrote:
 
> Hi internals,
> 
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` syntax
> instead of `<<>>` for attributes in PHP 8.
> 
> https://wiki.php.net/rfc/shorter_attribute_syntax
> 
> The goal is not to bikeshed over subjective syntax preferences,
> but to address several concrete shortcomings related to verbosity,
> nested attributes, confusion with generics and other tokens, and 
> dissimilarity to other common languages.

Just a heads up that the two week minimum discussion period expires
tomorrow, and I'm planning to open voting soon.

Best regards,
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Wed, June 10, 2020 at 3:11 AM Michał Brzuchalski 
 wrote:

> I just noticed a power of Rusts outer attributes which this syntax
> count follow in a future. Following outer attributes in Rust's we
> could introduce in a future syntax like
> 
>  #![StrictTypes,Module("my_module"),Opcache(save_comments: true)]
>
> The last one used with recently proposed named arguments which could
> open a wide range of possibilities IMO. In Rust adding exclamation
> mark after hash `#!` imposes to take effect on the outer scope which
> inside a file would be the whole file.
> 
> Going that path solution like that could possibly supersede
> `declare` statement in a future and allow to add compile-time
> attributes without breaking the language. I believe this is very
> important because any attribute which is not declared as a core and
> built-in is not taking an effect. This way it'd be possible to add
> new ones in future PHP versions. Even more with `zend_ast_process`
> it'd be possible to implement core attributes which take effect on
> whole file in extension.
> 
> I can imagine this can possibly be discussed to allow attributes for
> eg. from ctor to take effect on class but am not 100% sure of it is
> useful.

Hi Michał,

I'm really not certain it's a good thing to have another way of adding
declares which would be ignored in older PHP versions. For instance,
in your example if the code is designed to work with stricter types,
what happens if it's unexpectedly run on an older version of PHP?
Instead of erroring as it should, the code might keep running but
produce unexpected results for certain inputs.

> Going further with my imagination if we go that path with `#[Attribute]` 
> we may think of adding error suppression.
> I know many don't like error-suppression but sometimes it's helpfull.
>
> In case of core attributes I can imagine a const value can be added
> renamed or removed, but the attribute remains the same then adding
> error suppression in a future allows to avoid crashing like for eg.
> 
> #@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not, 
> but the Jit attribute does
> function foo () {}
> 
> In those cases we don't wanna crash the program, we may want it to
> continue rather without proper optimisation then not at all.
> 
> I just see another use of current error-suppression operator @ to
> play nice with attributes.

Please, let's not add a new place where error suppression can be used.
Yes, it's necessary when wrapping some old APIs that otherwise output
warnings, but for new APIs I really don't think this is a good idea.

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

Hi Sebastian,

On Wed, June 10, 2020 at 12:37 AM Sebastian Bergmann  wrote:

> Am 09.06.2020 um 17:57 schrieb Theodore Brown:
> > That's an interesting argument. After thinking about it more, though,
> > I'm not sure I understand what the benefit would be. The docblock
> > annotation needed for PHP 7 is *already* forward compatible with PHP 8.
> > So wouldn't this just be duplicating the attribute and opening the
> > possibility for them to be out of sync for no benefit?
> 
> This would allow the introduction of classes into PHPUnit such as
> 
>  namespace PHPUnit\Attribute;
> 
>  #[Attribute]
>  final class Covers
>  {
>  private string $coverageTarget;
> 
>  public function __construct(string $coverageTarget)
>  {
>  $this->coverageTarget = $coverageTarget;
>  }
> 
>  // ...
>  }
> 
> that can be used to encapsulate information that may come from a ...
> 
>  /**
>   * @covers \Foo\Bar\Baz
>   */
> 
> ... DocBlock-style annotation in PHP 7 but may also come from an ...
> 
>  #[Covers(Baz::class)]
> 
> ... attribute when PHP 8 is used.
> 
> This would make forward compatibility possible in code such as PHPUnit's 
> that currently supports DocBlock-style annotations but wants to support
> PHP 8 attributes and to deprecate (and later remove) support for
> DocBlock-style annotations.

So is the idea that PHPUnit 10 would still run on PHP 7.x, but would
also support native attributes for people running PHP 8? Maybe I'm
missing something, but wouldn't this be possible with the `@@` syntax
as well? The new `Covers` class would only be loaded if someone is
using attributes on PHP 8, so it's fine if it uses new PHP 8 syntax.
A parent class could be used to encapsulate coverage info for PHP 7.x.

To me it seems like the benefit of having (single-line-only) PHP 8
attributes treated as comments in PHP 7.x is being overblown. There
is already an upgrade path for docblock annotations to attributes.
Docblocks will continue working perfectly fine in PHP 8, so projects
and libraries can wait as long as needed before migrating to the
native attribute syntax.

Using `#[]` as the attribute syntax actually runs the risk of making
it *harder* for users to upgrade to PHP 8, since existing code that
uses hash comments starting with a left bracket would break.

Anyway, our plan is to hold a ranked-choice vote in the RFC between
`@@`, `#[]`, and `<<>>` syntax options, so if people prefer the
tradeoffs of borrowing Rust's syntax they can vote for it.

Best regards,  
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

Hi Benjamin,

On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote:

> Larry's suggestion about `#[Attr]` makes an important argument about
> allowing to declare attributes in code in PHP 7 in a forward compatible
> way that has not been brought up before.
>
> ```php
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
> ```
>
> This code would work on PHP 7 and 8.

That's an interesting argument. After thinking about it more, though,
I'm not sure I understand what the benefit would be. The docblock
annotation needed for PHP 7 is *already* forward compatible with PHP 8.
So wouldn't this just be duplicating the attribute and opening the
possibility for them to be out of sync for no benefit?

Rather than duplicating attributes, wouldn't libraries simply stick
with docblock annotations until they need to depend on other PHP 8
features anyway (e.g. union types), and then switch completely to the
native attribute syntax?

Furthermore, even if there was some benefit to having an attribute in
both docblock and native syntaxes, it seems like this is a very short
term concern. In a few years once libraries are depending on other
PHP 8 features, will this even matter anymore? So I'm really not
convinced that this forward compatibility argument should influence
the syntax choice.

> The `#[]` syntax would have about equally low breaking potential as `@@`.

Is this really the case? There's no benefit to adding extra suppression
operators, but I have seen code in the wild using hash comments starting
with an opening bracket (e.g. to comment out an array, or for making
checkboxes like `#[x] Some comment here`).

> As such, instead of going through each alternative syntax one by one,
> with with each having a 2/3 requirement to overthrow the old one,
> I would be open to restart the secondary vote on Attributes syntax
> with `<<>>` (status quo), `@@` and `#[]` using the same ranked voting
> algorithm that was used for the PHP 8 RM vote.

I'm certainly open to holding a three-way ranked choice vote like
this, if others are okay with it.

> I would take on the work to write about the third syntax alternative
> then. The VoteRFC could just link to the three individual RFCs where
> each discusses their syntax.

I added a section to the Shorter Attribute Syntax RFC discussing the
pros and cons of the `#[]` syntax. Let me know if you feel it isn't
worded fairly. I think it would be preferable to have the syntax
choices and voting options presented in one document rather than
spread out in different places if possible.

Best regards,  
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Mon, June 8, 2020 at 1:08 PM Markus Fischer  wrote:

> I noticed that my `@` character did bleed/meld almost with the first 
> character of the attribute name...wide characters like the `M` almost
> touch the `@`.

Hi Markus,

The first question that comes to my mind is, wouldn't this also be an
issue in all the other languages that use the `@Attr` syntax?
Personally I've used TypeScript decorators quite a bit, and the use
of the `@` character hasn't been a readability problem there.

I guess this mostly comes down to the font you use. E.g. here's how
the example looks for me in VS Code with the JetBrains Mono font:

https://imgur.com/a/qWQf6lz

And it's probably safe to say that syntax support/highlighting in
PhpStorm will be improved prior to the release of PHP 8.0. :)

Best regards,  
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Mon, June 8, 2020 at 10:01 AM Larry Garfield  wrote:

> FWIW, I find both alternatives ugly to my eye. So, there's that.  
>
> Given that `@` is off the table for obvious reasons, my preference
> would frankly be for Rust's `#[]`, which has the nice side effect
> of being a normal comment in earlier PHP versions and so attributes
> can be included as optional without breaking BC. I don't know if
> that's a big deal or not, but it's a benefit. And it should be no
> harder on the parser to differentiate than `@` vs `@@` is.
>
> (The only advantage of `@@` in my mind is another obvious Star Wars
> joke.)

Hi Larry,

>From the perspective of looks I don't have a strong preference
between them. There are two main reasons I decided against borrowing
the `#[]` syntax from Rust:

1. It's a much larger BC break. Disallowing comments from starting
with a certain character could break a lot of code in the wild.
>From a quick search of grep.app, I found two examples on the first
page of results using `#[` as a comment. [1] Is it worth breaking
this code?

2. `#[]` is slightly more verbose, which works against one of the
objectives of the RFC. Rust is the only language I found that uses
three characters for its attribute syntax like this.

I actually starting trying to draft an RFC which would propose the
`#[]` syntax for attributes, but one thing I noticed while doing
so is that (at least on my QWERTY keyboard) `#[` is noticeably
harder to type - I kept typoing it as `#]` or `#\`. This is dependent
on keyboard layout, of course, but being prone to accidental typos
was also one of the arguments against the `@:` syntax in the original
RFC.

> Something that I don't think has been addressed explicitly in this
> thread yet is single line vs separate line attributes.  Vis:
> 
> `<> class Blah {}`
>
> vs.
>
> ```php
> <>
> class Blah {}
> ```
>
> Syntactically both are legal AFAIK; I don't know which most people 
> will do. The separate line version seems more likely, and cleaner 
> to me, but for parameters people may want to inline it in shorter 
> signatures. Or it may push people to always multi-line those
> function definitions, for better or worse. (I find that quite ugly
> myself, but I don't know if I'm in the majority on that view.)
>
> My gut feeling is that `@@` is notably worse inline. It subjectively
> feels messier because there's no clear indication of where the end
> is. On separate lines, `@@` and `<< >>` seem about equally ugly to me.

Personally I have the opposite reaction when it comes to inline
parameter attributes - the closing `>>` always looks like a shift
operator at first glance which makes it harder for me to read. And
for an inline function or class attribute the function/class keyword
already provides a strong indication of where the attribute ends.

But for anything other than very short attributes, I expect most
people will want to put the attribute on a separate line for optimal
readability, regardless of the final syntax:

```php
function foo(
<>
< "val"])>>
Type $myParam,
bool $param2,
) {
...
}

// vs.

function foo(
@@ExampleAttribute("foo", "bar")
@@OtherAttribute(123, ["key" => "val"])
Type $myParam,
bool $param2,
) {
...
}
```

Best regards,  
Theodore

[1]: https://grep.app/search?q=%23%5B[lang][0]=PHP

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

Hi Rowan,

On Sun, June 7, 2020 at 5:32 PM Rowan Tommins  wrote:

> On 07/06/2020 19:37, Theodore Brown wrote:
> > Yes, I agree that there's a judgment call to make. Out of curiosity,
> > given these shortcomings of the double-angle-bracket syntax, do you
> > think there are any objective reasons to prefer it over `@@` (other
> > than the theoretical BC break of code like `@@@really_suppress_me()`)?
> 
> I'm not convinced there's any objective reasons to be found either way, 
> but for the sake of "playing devil's advocate", here are a few that 
> could be put forward:
> 
> If grouped attributes are added, they're actually slightly less verbose 
> than repeating a double-at prefix, once you have enough attributes in 
> the set:
> 
> Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving 
> even with 2 attributes:
> `<>class Bob{}`  
> vs  
> `@@Foo @@Bar class Bob{}`
> 
> More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more:  
> `<>class Bob{}`  
> vs  
> `@@Foo @@Bar @@Baz @@Quux class Bob{}`

Neither of these are realistic examples, though. In practice, you're
not going to have an empty class definition on the same line as a
bunch of short attributes like this. Based on the Use Cases section
of the Attributes v2 RFC, [1] typically there would be three or fewer
attributes applied to a given entity.

The RFC only has one example with four attributes, which happens to be
a flattened version of the nested attributes use case discussed in the
Shorter Attribute Syntax RFC. But in this example, the attributes each
have one or more parameters, which makes them long enough that they
have to be on separate lines. And with sane formatting, the `<<>>`
syntax version still ends up being more verbose:

```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
  ManyToMany(Phonenumber::class),
  JoinTable("users_phonenumbers"),
  JoinColumn("user_id", "id"),
  InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),
>>
private $phonenumbers;

// 160 characters for attributes
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
```

So the idea that the `<<>>` syntax with grouped attributes will be
less verbose than the `@@` syntax turns out not to be the case in
real-world use cases.

> Bracket-based syntaxes, particularly with grouping, are more clearly 
> separated from the main code, particularly when used inline. For instance:
> 
> `$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var) 
> {};`  
> vs  
> `$f = <> function(<> int $var) 
> {};`

To me there doesn't seem to be a big difference in readability between
the function attributes in this example. And with syntax highlighting,
the function keyword itself provides a very clear separation.

For the parameter attributes, the `@@` syntax example is actually
more readable to my eye. I can't help seeing the `>>` token as a
shift operator at first glance in this context.

> Finally, typing up those examples, it occurs to me that `@@` is quite a 
> "heavy" symbol - it has a large proportion of black (or whatever colour) 
> pixels - and inevitably a rather "fussy" one. I find it draws the eye 
> more than the angle-brackets do, which feels unfortunate.

I guess this is somewhat dependent on the font you're using. But in
general I don't think that the symbol being "heavy" is necessarily
a bad thing. It can help attributes stand out better from function
calls, generics, and other nearby syntax.

Best regards,  
Theodore

[1]: https://wiki.php.net/rfc/attributes_v2#use_cases

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

Hi Rowan,

On Sat, June 6, 2020 at 7:06 AM Rowan Tommins  wrote:

> The `::` token in the parser is called `T_PAAMAYIM_NEKUDOTAYIM`, and 
> personally I find `T_SL` and `T_SR` just as cryptic and irrelevant. The most 
> common place I see those token names is when accidentally running code 
> with conflict markers like "", or when messing up heredoc 
> syntax; even if they weren't so abbreviated, my reaction would be "shift 
> what now?" I've used bit-shifts maybe twice in the last ten years, so 
> it's just not an immediate association to me.
>
> "Disingenuous" was probably too strong a word, but I do think it relates 
> to a fundamental difference in viewpoint: to some people, `<<` and `>>`
> are first and foremost the shift-left and shift-right operators, and so
> the immediate association on seeing them is so obvious it's not worth
> mentioning; to others, they just look like a new kind of brackets.
> 
> That association might actually be a good reason to avoid that syntax, 
> but if so it should be spelled out, rather than taken as a given.

That makes sense. I updated the RFC now to avoid usage of "shift tokens"
in most places and instead refer to them as `<<` and `>>` tokens. I also
added a sentence spelling out why the association with shift operators
may be confusing for some developers.

Additionally, the RFC more clearly lays out the issues with nested
attributes now.

> > Also, grouped attributes would probably have to be special-cased to
> > be disallowed in nested attributes, since they don't make sense there.
> 
> I'm not entirely clear how they work in current implementations like 
> Doctrine's, but I think nested attributes would have to have completely 
> different rules anyway, because you don't access them directly through 
> reflection in the same way.
> 
> If `<> )>>` means something like `new Foo( new Bar )`, then I 
> can imagine it being useful for `<> )>>` to mean
> `new Foo( [new Bar, new Baz] )`. That would actually be more convenient than
> the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )`
> or use a constructor with a `...$variadic` parameter.

In that example there are the same number of characters either way, so
it's not clear the nested `<<>>` approach would be more convenient.
And do you think it's a good idea to have an additional syntax for
creating arrays like that? It seems like it could get confusing.

> Ultimately, it all comes down to judgement calls - is the 
> double-angle-bracket syntax "too verbose", "too ugly" when nested, etc; 
> and does the double-at syntax make it "better enough".

Yes, I agree that there's a judgment call to make. Out of curiosity,
given these shortcomings of the double-angle-bracket syntax, do you
think there are any objective reasons to prefer it over `@@` (other
than the theoretical BC break of code like `@@@really_suppress_me()`)?

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

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0

[Theodore Brown]

On Fri, June 5, 2020 at 4:24 AM Nikita Popov  wrote:

> On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas 
> wrote:
>
> >> It's that time of year again. Feature freeze is looming, so it's time to
> >> talk about deprecations!
> >>
> >> https://wiki.php.net/rfc/deprecations_php_8_0
> >
> > Thanks for the RFC.
> > Would it make sense for you to postpone this for 8.1?
> > I'm talking with my experience on Symfony here: we decided to give ppl
> > some rest when they upgrade and always have our *.0 versions
> > deprecations-free.
> > Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the
> > additional step of solving deprecations is extra work that is not needed
> > yet. I know solving deprecations is optional, but many teams have CI that
> > fail on deprecations.
> >
> > I think it could be nicer to the userland community to have a smother path
> > here, IMHO.
> 
> Hey Nicolas,
> 
> I'm certainly open to that! I don't think there's any strong reason to
> deprecate any of these in PHP 8.0 in particular, as we'll only be able to
> drop them in PHP 9.0 anyway. Anyone else have thoughts on that?
> 
> We do already have a couple of deprecation in PHP 8.0, but those are
> generally directly related to some change that happened in PHP 8.0 in
> particular.

Because I follow the internals mailing list and RFCs closely, I don't
personally feel too strongly about which version the deprecations are
in, since regardless I can make sure my own code doesn't use these
features.

But for the large body of PHP devs that don't follow internals,
wouldn't they want to be notified sooner if something will be
deprecated? Waiting almost feels like keeping the planned deprecations
a secret from outside developers, resulting in more code being written
using these features in the meantime, and when they are finally
deprecated the migration ends up being more work than it otherwise
would be.

So while I understand the desire to make upgrades as easy as possible,
I'm not convinced it's a good idea to delay these deprecations for
a later release. At the very least if deprecation is likely the PHP
manual should say something about it.

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Thu, June 4, 2020 at 12:19 PM Rowan Tommins  wrote:

> Hi Theodore,

Hi Rowan,

Thanks for the feedback. I added replies inline.

> I find the "objective" reasons in this RFC to be greatly exaggerated.
> 
> 1. `@@Jit` does not require "half as many characters" as `<>`;
> even for this, which is probably the shortest attribute anyone will
> ever use, the saving is less than 30%; for more common attributes
> which resemble entire function calls, it will be a tiny proportional
> saving.

By "half as many characters" the RFC is referring to the attribute
syntax itself, not the name/arguments of the attribute being used.
You're right that with longer attributes, the attribute syntax makes
up a smaller percentage of the code. However, I'd argue the savings
still has value even when it's a smaller proportion.

> 2. You don't actually explain why `@@Foo` would be any easier to
> integrate with nested attributes than `<>`. Is there some
> parser conflict that applies to one and not the other?

Martin can correct me if I'm wrong here, but I believe nested attributes
are syntactically possible with the `<<>>` syntax, but "ugly as sin"
(to quote Nikita). For example:

```php
<>,
<>,
)>>
private $groups;
```

Also, grouped attributes would probably have to be special-cased to
be disallowed in nested attributes, since they don't make sense there.
During implementation a bunch of work was put into trying to support
nested attributes with `new` (e.g. `new JoinColumn("User_id", "id")`),
but as the RFC mentions this was given up on since it turned out to be
very difficult to implement and would require lots of changes to const
expressions.

> 3. While confusion with generics is possible, I would be interested
> to hear from C# programmers how often they confuse `[Attribute]` for
> an array index operation, or any of the other uses of square brackets.

One reason I think confusion with generics is more probable is that
generics and attributes would frequently be used in a similar location
(near the start of a class declaration).

> 4. Similarly, I've yet to see anyone point to an example of confusion
> with shift operators that's not extremely contrived. I could come up
> with equally contrived examples where an attribute contained e-mail
> addresses and twitter handles, making `@@` look confusing.

Perhaps, though this seems much less likely since email addresses and
twitter handles would be in a string, whereas `<<` is a standalone
token used outside of strings.

> 5. No other language has been put forward using the `@@` operator. It
> more closely resembles those languages that use a single `@`, but the
> `<>` syntax more closely resembles those languages that use some
> form of brackets.

Fair enough. This doesn't really seem like an argument one way or
another.

> I also find it disingenuous that you refer to the `<>` syntax as
> "the shift tokens" throughout, but do not similarly call your proposed
> syntax "the double-suppression token". If one is "double-at", then the
> other is "double-angle-brackets".

I don't understand how it's disingenuous. The RFC refers to the shift
tokens as such because that's what they are (`T_SL` and `T_SR`). The
proposed `@@` syntax uses a new `T_ATTRIBUTE` token.

> The one convincing *objective* argument I've seen is Jordi's, that
> `@@` would be easily greppable. Interestingly, that's not true of
> any of the other languages listed in the comparison other than Rust's
> hash-bracket and maybe C++'s double-bracket, but that doesn't mean we
> can't do better.

Yes, I this is one reason I think having an `@@` token is a good fit
for PHP, as preserving easy greppability has influenced other syntax
decisions as well (e.g. the placement of return types).

> Other than that, I think it really comes down to a matter of taste. Some
> people reacted to the `<>` syntax the way they did to the Cats movie
> trailer, and may react to this one better. That's fine; we can make a
> decision for subjective reasons, but let's be honest and say that.

Well, I guess the line between objective and subjective may sometimes
be a bit subjective. :)

Best regards,  
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Thu, June 4, 2020 at 3:28 PM Marcio Almada  wrote:

> I'd also prefer any attribute syntax without the bracket-like pair
> of tokens. I'm just a bit confused about the RFC itself and the PR
> content at this point. 
>
> The RFC is currently proposing `@@MyAttribute()` and the PR
> is currently implementing `@:MyAttribute()` as the sigil. The first
> brings a BC break and the second doesn't, being the important
> difference.
>
> I'm inclined to `@:` instead of `@@`. Which one will actually be
> on the ballot? :D

Hi Marcio,

`@@` is the syntax that will be voted on. The linked PR is for the
original `@:` implementation, but as the RFC notes switching this
to `@@` just requires a single character to be changed in the lexer
and a small grammar adjustment. If the proposal is accepted we'll
submit a new PR with the updated implementation.

Apologies for the confusion!

Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Thu, June 4, 2020 at 6:55 AM Jordi Boggiano  wrote:

> Thanks for the write-up. I didn't feel strongly either way before but 
> after reading the RFC I am hoping it passes.
> 
> Another fringe benefit is the ability to grep for attributes, @@ does 
> not occur anywhere in a couple projects I checked, while << does occur 
> both as the << operator and heredocs/nowdocs. My fellow 
> grumpy-old-non-IDE-users might find this a valid argument too :)

Hi Jordi,

That's a good point. I have updated the RFC to briefly mention this
benefit as well.

Best regards,
Theodore

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Thu, June 4, 2020 at 5:39 AM Iván Arias  wrote:

> As we are creating new syntax, why not simply use another single
> symbol? Here are some examples:
>
> ```php
> *Deprecated  
> %Deprecated  
> >Deprecated  
>   
> function foo() { }
> ```
>
> I'm not 100% sure if all this symbols could by used in that context,
> but I think I prefer any of them rather than a double symbol.
> 
> Would it be possible to add a multioption vote and let people choose?

Hi Iván,

No, I don't believe possible to use any of those symbols. * already
means multiplication, % is used for modulus, > is for boolean
comparison, and & is for references.

The point of the RFC isn't to change styles to match a personal
preference about looks, but to solve several concrete shortcomings
with `<<>>` as laid out in the RFC.

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

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

On Thu, June 4, 2020 at 5:37 AM Ilija Tovilo  wrote:
 
>>> Does the PHP parser prevent us from adopting #[attr]? I presume
>>> C#'s [attr] syntax and C++'s  [[attr]] are impossible due to
>>> PHP's short array syntax.
>>
>> yes, that would create ambiguity in the parser since `#` (just
>> like `//`) is for comments.
>
> I've mentioned this off-list before. If we consider @@ with a BC
> break we could also consider #[] by making #[ a symbol.
> This is also a breaking change but a probably similarly small one.
> It would break code like this:
> 
> # Comments still work
> #[ <-- But they can't start with #[
> 
> To me both of those look acceptable but #[ looks nicer (but that's
> just my personal preference).

Hi Ilija,

>From the perspective of looks I don't have a strong preference
between them. There are two main reasons the RFC doesn't propose the
`#[]` syntax. First of all, I would consider this a larger BC break
than `@@`. Although hash style comments are relatively uncommon, some
codebases do use them, and I don't think we can presume to say that
it "isn't useful" to begin a comment with a `[` (as can be said about
using multiple suppression operators).

Secondly, the `#[]` syntax is 50% more verbose than the two character
`@@` proposal; Rust is the only language I found that uses three
characters for its attribute syntax like this.
```

Best regards,
Theodore

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

[PHP-DEV] [RFC] Shorter attribute syntax

[Theodore Brown]

Hi internals,

I discussed the syntax for attributes further with Benjamin, Martin,
and several other internals developers off-list, and with their
feedback completed an RFC proposing to use the shorter `@@` syntax
instead of `<<>>` for attributes in PHP 8.

https://wiki.php.net/rfc/shorter_attribute_syntax

The goal is not to bikeshed over subjective syntax preferences,
but to address several concrete shortcomings related to verbosity,
nested attributes, confusion with generics and other tokens, and 
dissimilarity to other common languages.

Best regards,
Theodore

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

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Theodore Brown]

On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei  wrote:

> the Attributes RFC was rather large already, so a few things were left
> open or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <

Hi Benjamin,

I find the grouped attribute proposal somewhat troubling. The RFC
contains the following example:

```php
<>
public function test()
{
}
```

The problem with this syntax is that adding a new attribute at the 
start or end of the list, or removing one of the attributes, will
require modifying multiple lines. For some time the language has been
moving away from this (see the various RFCs to allow trailing commas
in more places), so this feels like a step backwards.

If trailing commas are allowed in grouped attributes, you could
write it this way instead:

```php
<<
  Attr2("foo"),
  Attr2("bar"),
>>
public function test()
{
}
```

But to me this still feels rather clunky. It requires two extra lines, 
and when moving from two attributes to one attribute (or vice versa),
you'd still probably end up modifying multiple lines.

Another issue with the grouped syntax is that comma separated
attributes can be easy to confuse with comma separated attribute 
arguments. For example:

```php
<>
<>
function bar() {}
```

It can be hard to tell which line contains multiple attributes vs.
multiple attribute arguments.

Ultimately it seems like the grouped attribute proposal is attempting
to work around the poor usability of the current verbose syntax. Maybe
it would be better to instead propose a simpler syntax that avoids
these issues. I know that some internals members expressed interest
in an `@@` token, but this was never voted on.

Having a distinct token for attributes would entirely avoid the issues
of having to modify multiple lines when adding/removing attributes, as
well as confusion with shift operators and comma-separated attribute
arguments. E.g. the RFC example would look like this instead:

```php
@@Attr2("foo")
@@Attr2("bar")
public function test()
{
}
```

To me this would be a lot cleaner and fit in better with the rest of
the language.

Best regards,
Theodore

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

Re: [PHP-DEV] [RFC] Named arguments

[Theodore Brown]

On Tue, May 5, 2020 at 9:11 AM Marco Pivetta  wrote:

> As mentioned some days ago, I see named parameters as an added liability,
> rather than values.
> The rationale of my negativity around the topic being that a diff like
> following is now to be considered a BC break:
> 
> ```diff
> -function foo($parameterName) { /* ... */ }
> +function foo($newParameterName) { /* ... */ }
> ```

If the function is part of your own codebase, an IDE can automatically
update function calls when renaming a parameter. For functions that are
part of a public API, yes, parameters shouldn't be renamed outside of
major versions. But in my experience, it's rare for function parameters
that are part of public APIs to be renamed. Do you have many real-world
examples of where this had to happen?

Also, I haven't heard of this being a big problem in other languages
with named arguments like Python.

> the feature seems to be especially designed to work with particularly
> bad API (anything with a gazillion optional parameters, such as all
> the OpenSSL nightmares in php-src).

Why do you say that? For me this feature would be extremely helpful
when calling constructors that have several optional arguments (e.g.
similar to the `ParamNode` example in the RFC). Maybe you consider
this a bad API, but it's a very common pattern, and named arguments
will make it far easier to work with than the typical alternative of
converting arguments to an options array (which is itself a BC break
and has many other downsides as the RFC points out).

> In practice, the issues around bad API (in this case, bad = lots of
> optional parameters, maybe even ordered arbitrarily) are fixed by
> using proper value types and structs or value objects

How can lots of optional parameters be "fixed" in practice with structs?
E.g. how would they improve the `ParamNode` example in the RFC? Would
it even be possible to migrate existing classes like this to structs
without a BC break?

Personally I think it's a lot simpler and more consistent to have named
arguments which can be used anywhere, including in attributes, vs.
having to implement and learn a new syntax for structs which only works
for that one use case (and may not be easy to migrate to).

Best regards,

Theodore Brown

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

Re: [PHP-DEV] [VOTE] Attributes v2 RFC Vote is open

[Theodore Brown]

On Mon, Apr 20, 2020 at 4:18 AM Benjamin Eberlei  wrote:

> I have opened the vote on the Attributes v2 RFC. The voting will be
> open until two weeks from now, May 4th 2020, noon UTC.
>
> RFC: https://wiki.php.net/rfc/attributes_v2

It's unfortunate that the RFC doesn't more fully enumerate the
advantages/disadvantages of the proposed syntax options.

It only points out that the T_ATTRIBUTE `@:` syntax is shorter and
more familiar, but claims that it has the downside of not permitting
whitespace in attribute names (it's not clear this is really an
advantage - just an opportunity for arguments about code style).

But if you look at the pull request for the `@:` syntax [1], there is
a much more complete comparison. For example, the `<<>>` syntax is more
verbose, unfamiliar to most people, and even Hack seems to be moving
away from it. Furthermore, because it reuses existing tokens with a
different meaning, it results in expressions that can be very difficult
to read. For example:

```php
const Baz = 2;

<><>
<>Baz, (4 + 5) * 2)>>
function foo() {}
```

If PHP gets generics in the future (hopefully it does), the syntax will
likely get even more confusing (if not a lot of PHP developers use shift
tokens, certainly a lot more will use generics).

The `@:` syntax makes it much more obvious where separate attributes
are being used vs. constant expressions containing a shift token:

@:FooAttribute(2 * 3 + 3)
@:Bar(4 + 5 * 2)
@:BarAttribute(2 * (3 + 3)>>Baz, (4 + 5) * 2)
function foo() {}
```

In addition, the `@:` syntax is less verbose, and much closer to the
attribute syntax developers are familiar with using in PHPDoc comments,
as well as the syntax with precedence in other languages such as Java
and Python.

The syntax choice is very important, the language will be stuck with
it for a very long time!

Best regards,
Theodore

[1]: https://github.com/kooldev/php-src/pull/2

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

Re: [PHP-DEV] Re: [RFC] Attributes v2

[Theodore Brown]

On Fri, Apr 17, 2020 at 12:43 PM Benjamin Eberlei  wrote:

> On Fri, Apr 17, 2020 at 6:11 PM Theodore Brown  wrote:
> 
> > Can you provide an example of an attribute name containing whitespace
> > that would be allowed with the shift left/right tokens but not with the
> > attribute token?
> 
> This is about [whitespace] between token and attribute name, so `@:Foo`
> is allowed but `@: Foo` is not. Whereas with the hugging As, `<>`
> and `<< Foo >>` is allowed.

Ah, that makes a lot more sense. Thanks for the clarification. I guess
allowing whitespace could also be considered a downside, since it will
lead to style guide wars about which spacing convention to use.

> This is a personal assumption here, but I would assume 95% of developers
> have never used >> or << before or for a long time and maybe 80% don't
> even know what bit shift means and how it works. I would think nobody
> needs this in attributes.

Even if bit shifts are rarely used, the fact that such syntax is valid
means there's a higher cognitive load when reading attributes to
understand whether a shift token is part of a parameter value or
delineating the start/end of an attribute declaration.

Quick, does this function have two attributes with one parameter each,
or one attribute with two parameters?

```php
<><>
function foo() {}
```

How about this one?

```php
const Foo = 2;

<>Foo, (4 + 5) * 2)>>
function foo() {}
```

Even if the syntax is technically unambiguous, reusing shift tokens as
attribute delineators results in symbol-heavy code which is harder to
quickly and correctly understand.

FWIW Hack is apparently moving away from the shift token attribute
syntax to one using `@` (see 
https://github.com/facebook/hhvm/commit/3983bd2ca6b252a93d98f2bb2d7e8e89f6f004d1);

Sincerely,
Theodore

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

Re: [PHP-DEV] Re: [RFC] Attributes v2

[Theodore Brown]

On Fri, Apr 17, 2020 at 5:49 AM Benjamin Eberlei  wrote:

> As there has only been minimal new discussion after the last changes to the
> RFC I wanted to give a heads up that I will open the vote on Monday
> afternoon.
> 
> If you have further remarks or questions about the RFC, please let me know.
> 
> On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei  wrote:
> 
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2

Hi Benjamin,

Thanks for working on this RFC. I have a couple questions and
thoughts about the proposed syntax options.

First, the RFC says that the alternate T_ATTRIBUTE `@:` token has the
downside "that it does not permit whitespace in attribute names to
allow detecting the ending of the declaration." Can you provide an
example of an attribute name containing whitespace that would be allowed
with the shift left/right tokens but not with the attribute token?

The RFC says that "Semantically the attribute declaration should be
read as instantiating a class with the attribute name and passing
arguments to the constructor." But class names can't contain spaces,
so how is it a downside for attribute names to not permit them either?
It seems like it would be a massive footgun to allow attribute names
that *can't* resolve to a class name, since there would be no way to
migrate them to a declared attribute class without a BC break. For this
reason, regardless of the final syntax choice I think whitespace should
not be permitted in attribute names.

Secondly, given that attribute arguments are evaluated as constant
expressions, it's far easier for me to read the T_ATTRIBUTE `@:` syntax
at a glance than the syntax reusing shift left/right tokens. With the
latter my eyes tend to confuse shift left/right tokens in a constant
expression with the open/close token of an attribute (especially since
the syntax using bit shift tokens allows multiple attribute declarations
on the same line).

Consider this example using the shift left/right token syntax:

```php
<> 1, 4 << 1)>><> 1, 4 << 1)>>
function foo() {}
```

To me the same thing using the T_ATTRIBUTE syntax is far more readable:

```php
@:BitShiftExample(4 >> 1, 4 << 1)
@:OtherAttribute(4 >> 1, 4 << 1)
function foo() {}
```

Best regards,
Theodore

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

Re: [PHP-DEV] Re: [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Theodore Brown]

On Tue, Feb 25, 2020 at 9:59 AM Nikita Popov  wrote:

> On Thu, Feb 13, 2020 at 10:47 AM Nikita Popov  wrote:
>
> > This has been discussed a while ago already, now as a proper proposal:
> > https://wiki.php.net/rfc/token_as_object
> >
> > An open question is whether (at least to start with) PhpToken should be
> > just a data container, or whether we want to add some helper methods to it.
> > If this generates too much bikeshed, I'll drop methods from the proposal.
>
> I think this proposal is in a pretty decent shape now, and I'd like to move
> it to voting soon. The only remaining open question is whether we want to
> add any additional predefined methods. As the class can now be extended,
> every library can add their own methods, but there might still be value in
> providing some things by default, primarily for performance reason. For
> example, the proposed is() method can be a good bit more efficient when
> implemented directly in extension code.
>
> Any feedback on this point?

Hi Nikita,

Thanks for this RFC. The proposed `PhpToken` class will definitely make it
easier to work with parsed tokens (I struggled with this when working on
the migration script for deprecated alternate array/string offset syntax).

In regards to the open question of additional methods, the `getTokenName()`
method would be very welcome. `isIgnorable()` would also be helpful
sometimes, though I don't care much one way or another if it's added.

But I'm really skeptical about the value of the `is($kind)` method. Code
working with tokens should know the type of value being checked (ID int,
text content, or array of one or the other), and a method that accepts
any of three types can make it harder to understand what's going on.

For example, the proposed `isIgnorable()` method doesn't need to use
`is()`, it could just check whether the `id` property is in the array
of token constants.

Best regards,
Theodore

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

[PHP-DEV] Re: [VOTE] declare(function_and_const_lookup='global')

[Theodore Brown]

On Tue, Jan 28, 2020 at 8:22 PM tyson andre  wrote:

> Hi internals,
>
> I've opened the vote on https://wiki.php.net/rfc/use_global_elements

Thank you for working to address the issue of ambiguous function references. 
However, I really don't think this is the right approach.

The RFC mentions two problems it hopes to solve: a minor performance decrease, 
and developers having to deal with ambiguity. However, a third problem that I 
think is just as important to fix is the lack of function autoloading which 
makes extensive use of namespaced functions unfeasible.

Unfortunately, the new directive proposed by this RFC would make declaring 
functions in namespaces even more difficult, as it would now be necessary to 
explicitly `use` each function and constant in the same file it is declared in. 

The RFC argues that having to "add multiple `use function function_name` and 
`use const MY_CONST` at the top of the namespace" is prone to merge conflicts 
and inconvenient to keep up to date. However, the RFC just shifts this problem 
from global functions to namespaced functions.

Changing function/const resolution to always look in the global scope instead 
of current namespace is backwards from how classes and interfaces are resolved, 
and seems destined to become another language Sadness. Wouldn't it be more 
straightforward and intuitive to add a directive like 
`declare(namespace_lookup=1)` which would resolve functions/consts the same way 
as classes (without the global fallback)?

The RFC argues that writing global functions as `\function_name()` is more 
verbose. But is one backslash character per global function call any more 
verbose than having to add a 44-character declare statement at the top of every 
file? Developers are already used to referencing global classes and functions 
with backslashes or explicit `use` statements, and in a future where we have 
function autoloading and utilize more namespaced functions, this approach will 
be less verbose than having to explicitly `use` every namespaced function in 
the same file it is declared in. Plus, IDEs and other tools can automatically 
add the backslashes or `use` statements for global functions.

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

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

[Theodore Brown]

On Sun, Jan 26, 2020 at 10:25 AM tyson andre  wrote:

> https://wiki.php.net/rfc/use_global_elements and the implementation
> has been updated again - the syntax is now 
> declare(function_and_const_lookup='global')
> with a literal string instead of a keyword.

> The voting option for whether it was a string or a keyword was removed.
> I plan to move this to the voting phase on Monday, if nothing else
> needs to be addressed

I have a few questions and concerns:

1. Is it a typo that the first code example in the proposal has a
namespace declaration before the `declare` statement? Currently it is
a fatal error if a `strict_types` declaration isn't the first
statement in a file. Are you intending to change this restriction,
or have it not apply to the `function_and_const_lookup` declaration?

2. How will this RFC fit into "future work on autoloading" (mentioned
as a benefit in the discussion section)? Would autoloading only be
possible for files with `declare(function_and_const_lookup='global');`?

This RFC seems like a pragmatic attempt to solve the global/namespaced
ambiguity issue for the way code is typically written today (most
const/function uses in a namespace being global yet unqualified).
However, isn't the current lack of autoloading part of the reason for
this usage pattern? Personally I would love to write more plain
functions in namespaces, but am forced to use static class methods
instead to benefit from autoloading.

In other words, if PHP had function autoloading, there would be more
usage of namespaced functions, in which case changing function and
const lookup to global becomes less helpful. In this way the RFC seems
to work against one of its own goals.

I would find it quite annoying and counterintuitive to have to
explicitly `use` namespaced functions and consts in the same file
they are defined in. The example in the RFC of a function defined in
a namespace that appears to call itself but actually calls a different
global function is particularly confusing.

I'd really like to see a more complete proposal that thinks through
how it will fit in with future autoloading and the way people will
then write code, rather than just the way they write it today due to
current limitations.

Long term I think it would be better to have a `declare(global_lookup=0)` 
option which could be applied to a set of namespaces, and a registered
function/const autoloader would only be triggered for those namespaces.
This would allow function autoloading to be used without hurting performance or 
breaking existing libraries.

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

Re: [PHP-DEV] Warn when declaring required parameter after optional one

[Theodore Brown]

On Fri, Jan 17, 2020 at 11:59 AM Nikita Popov  wrote:

>> I've created https://github.com/php/php-src/pull/5067 to make code like
>>function test($foo = null, $bar) {}
>> throw a warning
>
> I was interested in seeing how prevalent this pattern, is, so I ran
> some analysis on the top 2k composer packages. I found 527 signatures
> that would throw a deprecation warning with this change. Of these 187
> are potentially used as "poor man's nullable types" (the optional
> argument has both a type and a null default), while the other 340 are
> definite bugs.

Given that most of these usages are definite bugs, I'm in favor of
deprecating this in PHP 8 and making it a compile error in PHP 9. This
should provide plenty of time for codebases to migrate to the simpler
nullable types syntax for the minority of usages that aren't bugs.

Theodore

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

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Theodore Brown]

On Tue, Oct 8, 2019 at 6:02 AM Reinis Rozitis  wrote:

> Not directly related to this RFC but out of curiosity - where does
> this "doing the same thing in multiple ways is confusing" comes from?
> (I mean this as serious question)
>
> I had the impression that programming in essence is all about that -
> achieving/accomplishing something/the same different ways?

Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing. The
latter is confusing since it's no longer clear which syntax should be
used. The same situation existed with the curly brace array/string
access syntax, which was deprecated in PHP 7.4.

To share my own experience, when I first started needing to run shell
commands in PHP and came across the backtick operator, I struggled to
understand the difference between it and `shell_exec`, and which
should be used in different circumstances. E.g. does the backtick
operator automatically escape variables? Is it faster than
`shell_exec`? It also caused me to assume that `shell_exec` must be
preferred for some reason over `exec` and `proc_open` since there is
a dedicated syntax for it.

Ultimately it made the whole process of learning how to correctly run
commands from PHP a lot more confusing than it should have been.

I know I'm not the only one that has been confused by it. If you look
at the PHP manual page for Execution Operators [1], the top voted
comment (by far) is from someone who accidentally typed a backtick
into their code and had a very difficult time debugging why their
script didn't work as expected.

As I see it, this syntax is not only confusing, but also dangerous.
A programmer coming from JavaScript might think the backticks are
simply storing a string, when in fact it will be executed as a command.
Furthermore, the (undocumented) ability to include variables in the
command can encourage terse but insecure scripts which fail to
properly escape user-supplied arguments.

Theodore

[1]: https://www.php.net/manual/en/language.operators.execution.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Theodore Brown]

On Mon, Oct 7, 2019 at 2:50 AM Nikita Popov  wrote:

> On Fri, Oct 4, 2019 at 5:45 PM Mark Randall  wrote:
> 
> > Hi Internals,
> >
> > I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> > discussion.
> >
> > https://wiki.php.net/rfc/deprecate-backtick-operator-v2
> >
> > I believe it is at least worth a discussion as to the pros and cons of
> > deprecating this functionality, especially in light of the existence of
> > better described and more well-known functions exhibiting identical
> > behaviour.
> >
> > This RFC only covers the issuing a deprecation notice, and its complete
> > removal would be contained within a separate RFC.
> >
> 
> Usage of backtick operator in packagist top 2k packages:
> https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594
> There are 72 occurrences including duplicates.
> 
> Make of that whatever you will :)


I did some further analysis on the output of Nikita's script.
Ignoring the duplicate WordPress package, all the occurrences
are in just 21 unique projects.

In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two occurrences.

Raw numbers: https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Theodore Brown]

On Wed, Aug 28, 2019 at 4:33 AM Nikita Popov  wrote:

> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really quite mind-boggling.
>
> I've prepared an RFC with some suggested classifications, though there's
> room for bikeshedding here...
>
> https://wiki.php.net/rfc/engine_warnings

Nikita,

Thank you for your effort in putting together this RFC and explaining
the rationale for each change. From my perspective, converting more
error conditions from a notice/warning to an exception as proposed
will be a welcome step forward for the language.

I've frequently used PHP to write one-time scripts for migrating data
between services, or scripting changes to thousands of items via an
API. The lack of exceptions for things like undefined variables and
using a scalar value as an array has bitten me on multiple occasions.

There have even been times when simple mistakes like a typo in a
variable name have led to data loss, since instead of causing the
script to halt it just output a notice and continued running with
bad data.

In my experience, PHP's historical lax treatment of errors, far from
making it faster and easier to write scripts, *actually makes it take
longer* since I have to add extra assertions and boilerplate custom
error handling code in order to ensure that scripts don't keep
running in a broken state when one of these errors occurs.

So in summary, I think the proposed RFC is a solid step forward which
will help prevent expensive mistakes and make it simpler to write
robust code.

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

Re: [PHP-DEV] Re: Call for participation: Annotating internal function argument and return types

[Theodore Brown]

On Tue, Aug 27, 2019 at 5:00 PM Dik Takken  wrote:

> It had been quiet on the list since I offered to help out, so I
> completely missed people were already working on this.
>
> To avoid any duplication of work, just assign me a couple of extensions
> that nobody is working on yet and I will see what I can do.

There's no need to wait to be assigned - feel free to pick any of the
extensions that haven't been migrated yet and don't have pending PRs.

For the bigger extensions that take longer to migrate, it's okay to
submit a WIP pull request to avoid duplication of work.

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Theodore Brown]

Seems good to me.

Short tags have long presented a risk of code leakage and lack of portability, 
since they are dependent on an ini setting which not everyone has enabled.

Hopefully this can land in time for PHP 7.4.

From: Nikita Popov 
Sent: Monday, June 17, 2019 5:55 AM
To: Peter Kokot
Cc: Zeev Suraski; G. P. B.; Stanislav Malyshev; Derick Rethans; PHP Internals 
List
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

On Fri, May 24, 2019 at 6:53 PM Peter Kokot  wrote:

> Hello,
>
> On Sat, 11 May 2019 at 20:56, Peter Kokot  wrote:
> >
> > Not trying to rush anyone to something they have no energy working on
> > anymore here but what's the plan here then? And what plan is there
> > with these short tags on the long run?
>
> I'm just checking then why is this RFC in the pending implementation
> state if basically we're on a way to have the short opening tags in
> PHP for ever... Maybe we should then enable them by default to have
> the other way around situation of having both tags for few 10 years
> and then ditch the long one if it's not going to be deprecated in PHP
> 7.4 and decided what to do with them?
>
> https://wiki.php.net/rfc/deprecate_php_short_tags
>

Girgias has put up a new implementation at
https://github.com/php/php-src/pull/4263.

If short_open_tag=On and 

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Theodore Brown]

On Mon, July 8, 2019 at 9:10 AM Sara Golemon  wrote:

> On Sun, Jul 7, 2019 at 3:45 PM Theodore Brown  wrote:
> 
> > For those voting against adding these functions, can you clarify why?
> 
> Explaining my non-vote. I'm explicitly abstaining as I don't see the
> value in these functions (I'd rather see a community driven library
> which does the same thing in a more agile way), but neither do I see
> much intrinsic harm in allowing these functions in.

Thanks Sara. I understand your perspective of not wanting to add more
functions to PHP core which can be easily implemented in userland.

However, when it comes to basic string functions which are needed in
almost every script, I don't think it makes sense to ask users to
depend on an extra library for this. Almost every other language
has built-in functions for simply checking if a string starts or ends
with another string.

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

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Theodore Brown]

On Thu, July 4, 2019 at 9:13 PM Will  wrote:

> Hello all,
>
> After 15 days of discussion I have opened up voting on the following
> RFC (https://wiki.php.net/rfc/add_str_begin_and_end_functions).


Thank you for your work on this. I'm surprised that so far the vote
is so controversial, with 8 votes in favor and 8 opposed.

For those voting against adding these functions, can you clarify why?
Do you dislike how they are named, or do you not see the need for the
case insensitive versions, or is there an issue with the implementation?

Personally I'd find the basic `str_starts_with` and `str_ends_with`
functions very valuable. Currently I either have to implement functions
like this myself in almost every script, or else write repetitious
code like the following:

```php
$needle = "foobar";

if (substr($haystack, 0, strlen($needle)) === $needle) {
// starts with "foobar"
}
```

To avoid repetition, many developers use the following pattern instead:

```php
if (strpos($haystack, "foobar") === 0) {
// starts with "foobar"
}
```

However, with longer strings this becomes far less efficient, since PHP
has to search through the entire haystack to find the needle position.

If this RFC is accepted, these awkward and inefficient approaches
could be replaced with straightforward and fast code like this:

```php
if (str_starts_with($haystack, "foobar")) {
// ...
}
```

Please vote on the RFC if you haven't already. Clarification would be
appreciated if don't feel that these functions would be a good addition.

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

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Theodore Brown]

On Thu, July 4, 2019 at 9:13 PM Will  wrote:

> After 15 days of discussion I have opened up voting on the following RFC 
> (https://wiki.php.net/rfc/add_str_begin_and_end_functions) .
>
> You can access the voting page here: 
> https://wiki.php.net/rfc/add_str_begin_and_end_functions/vote
>
> I have never set up a vote on doku-wiki so please let me know if I made 
> the vote incorrectly!

It seems really unusual for voting to be on a separate page than the
RFC. Can you move the doodle voting macro to a "Vote" section on the
main RFC page?

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

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Theodore Brown]

On Thu, July 4, 2019 at 5:26 PM Björn Larsson  wrote:

> Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:
>
> > Thanks for taking the time to push forward this RFC.
> >
> > I found the earlier discussion at https://externals.io/message/104744,
> > which I hadn't seen. Like others, I would have chosen to keep {} for
> > string offsets to make it clearer, though I have not used {} in my
> > code for a decade. Was any consideration given to a split vote,
> > voting on the array and string deprecations separately?
> >
> > For others interested, the history of this deprecation going back to
> > 2005 is found at https://externals.io/message/38153
>
> Hi,
>
> I have the same question regarding split vote. In my eyes the
> array case is a no-brainer, but for string access maybe not...


Good question. I did consider whether it would make sense to only
deprecate curly brace offset access for arrays and not strings. The
problem with this is that it wouldn't solve the issue of confusion
outlined in the RFC.

Unless the bracket syntax for string offset access was also
deprecated, users would still be left to question whether the curly
brace syntax behaves differently in certain circumstances, if one
alternative performs better than the other, if there is a scoping
related difference, or when the curly brace syntax should be used
instead of the normal bracket syntax for string offset access.


> Would it be possible to compare the string access only for both
> curly & straight braces and the same for array access?

I updated my script to list all the unique variable names referenced
in the output of Nikita's analysis of the top 2k Composer packages:
https://gist.github.com/theodorejb/ba35fc8f72df8823e07c5f3b51870e00.

The most frequent variable name is `$string`, and from numerous other
variable names it does seem that the majority of curly brace usages
are on strings (other frequent variable names include `$code`,
`$Bytestring`, `$chrs`, `$text`, `$str`, `$numberstring`, and many
similar examples). I also dug into the repositories for a bunch of
the packages, and most of the curly braces uses appear to be in older
code without any type declarations (which may explain why so many
variable names include a type).

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

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Theodore Brown]

On Wed, July 3, 2019 at 10:59 AM Nikita Popov  wrote:

> On Wed, Jul 3, 2019 at 4:41 PM Levi Morrison  wrote:
> 
> > Was any analysis of usage done for top open source projects? I support
> > this direction, but would prefer to know its current impact before
> > voting.
> 
> 
> I checked top 2k projects with a 2-3 months outdated data set. Here is the
> analysis log: 
> https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e
> 
> Overall there were ~2.2k individual uses of alternative array syntax. To
> put that into context, there 888.3k total array accesses in the data set,
> which puts usage at about 0.25%. Uses are usually clustered, i.e. if
> alternative array syntax is used in a file, it will be used many times.

I did some additional analysis on the output of Nikita's script. The number
of curly brace usages is inflated somewhat due to duplicate packages. For
example, tecnick.com/tcpdf and tecnickcom/tcpdf both have 74 usages, and
are the same project which was renamed. Likewise, johnpbloch/wordpress-core
and roots/wordpress each have 182 usages, and they are both mirrors of the
WordPress core codebase. Another example is magento/zendframework1 which was
forked from zendframework/zendframework1 (almost half the curly brace usages
have been removed in the magento fork).

53 out of 89 total packages using the curly brace syntax use it 4 or fewer 
times.
92% of the usages in are in just 25 unique projects.

You can view my script and its output here:
https://gist.github.com/theodorejb/ba35fc8f72df8823e07c5f3b51870e00

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

Re: [PHP-DEV] [RFC] Deprecations for 7.4

[Theodore Brown]

On Fri, Jun 21, 2019 at 10:20 AM Kalle Sommer Nielsen  wrote:

> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.
>
> https://wiki.php.net/rfc/deprecations_php_7_4

It's still unclear what is being proposed for the register_argc_argv
ini directive. When the ini setting is removed, will the `$argv` and
`$argc` variables always be available on CLI SAPIs, and never be
available on non-CLI SAPIs?

If that's the case, I'd propose a deprecation notice in PHP 7.4 when
using `-d register_argc_argv=0` on the command line, and when accessing
the predefined `$argv` or `$argc` variables from non-CLI SAPIs.

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

[PHP-DEV] Re: [RFC] [VOTE] Numeric Literal Separator

[Theodore Brown]

On Thu, May 30, 2019 at 7:50 AM Theodore Brown wrote:
 
> Voting has now started on the Numeric Literal Separator RFC:
> https://wiki.php.net/rfc/numeric_literal_separator
> 
> This feature is widely supported in other languages, and can be very
> helpful for improving code readability and clarifying intent.
> 
> Voting will end in two weeks, on 2019-06-13.

Hi internals,

I'm pleased to announce that this RFC has been accepted, with 33
votes in favor and 11 against. Thank you to everyone who voted!

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

Re: [PHP-DEV] Wiki display problem

[Theodore Brown]

On Mon, June 3, 2019 at 7:11 AM Andreas Heigl  wrote:

> Looks like the stylesheets are loaded from shared.php.net which still
> seems to be on an old certificate. Therefore the styles are not loaded

Styles are loading for me, but I get a certificate error when I try to open
https://people.php.net.

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