Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
On 24-2-2024 3:47, Gina P. Banyard wrote: On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer wrote: Hi Gina, I'm not sure a pet-peeve is a good motivation for creating an (I expect large) breaking change. The upgrade path, I suppose, would be updating calls to `die`/`exit` to always have parentheses ? Or alternatively changing those calls to new throw expressions ? While that shouldn't be that huge a problem for real codebases (and would be auto-fixable for adding the parentheses), the bigger problem I see is the huge amount of teaching materials, tutorials and blog posts using the versions without parentheses which will now all be invalidated. I think the pain and confusion that will cause for a change like this, will linger for years and years. Smile, Juliette I didn't actually know one could do exit; But like I said, it is extremely easy to support, and the current PR does support it by hooking into the undefined constant code in the engine. I don't have strong opinions about removing support for this. However, I do have strong opinions about changing the type juggling semantics of exit() to be the usual ones, because the current one is just confusing. I am also not sure what would make this a large breaking change, as changing this from a language construct to a function provides us with more capabilities. Ah, I think I missed the part about the syntax both with and without parentheses still being supported, with the "with parentheses" mapping to a function call and the "without parentheses" mapping to a case-insensitive constant. In that case, I don't see a BC-break and I would regard this as an "under the hood" change with only a very subtle, minimal impact (the type checking part if a param is passed). I do wonder what the documentation would look like as it would leave it as a function, but one with a special status, in that there is a native constant of the same name which will enforce the same behaviour. Smile, Juliette
Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer wrote: > Hi Gina, > > I'm not sure a pet-peeve is a good motivation for creating an (I expect > large) breaking change. > > The upgrade path, I suppose, would be updating calls to `die`/`exit` to > always have parentheses ? Or alternatively changing those calls to new throw > expressions ? > > While that shouldn't be that huge a problem for real codebases (and would be > auto-fixable for adding the parentheses), the bigger problem I see is the > huge amount of teaching materials, tutorials and blog posts using the > versions without parentheses which will now all be invalidated. I think the > pain and confusion that will cause for a change like this, will linger for > years and years. > > Smile, > Juliette I didn't actually know one could do exit; But like I said, it is extremely easy to support, and the current PR does support it by hooking into the undefined constant code in the engine. I don't have strong opinions about removing support for this. However, I do have strong opinions about changing the type juggling semantics of exit() to be the usual ones, because the current one is just confusing. I am also not sure what would make this a large breaking change, as changing this from a language construct to a function provides us with more capabilities. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
On 24-2-2024 2:37, Gina P. Banyard wrote: Hello internals, I've been having this mild annoyance with exit()/die() since I wrote a CLI script using a boolean $hasErrors variable to know if the script failed or not and to indicate if the script failed via a non-zero status code by doing: exit($hasErrors); However, it turns this doesn't work, because exit() will cast everything that is not an integer to a string, something that I find surprising but also weird as it will not type error on resources or array but rather print the warning to the CLI. Anyway, yesterday I decided to put on my mad scientist lab coat and make this a reality, I have a W.I.P. PR here: https://github.com/php/php-src/pull/13483 I hear you, but what about exit; ?! Do not worry exit; is still supported! It only requires a _tiny_ bit of dark magic to achieve this! exit; would just be interpreted as a fetch to a constant, so when attempting to access the undefined exit/die case-insensitive constant we just need to exit as if we were calling the function! Having exit and die be functions gives us access to some interesting functionality, such as defining exit() in a namespace, or removing it via the disable_functions INI setting (the latter allowing us to define a custom global exit() which could be useful for testing that a function actually calls exit). We can also pass it like any other callable and reflect on it with reflection. Finally, this removes the T_EXIT token and ZEND_EXIT opcode freeing one slot. The W.I.P. PR implement every possible restriction: - not being able to declare an exit()/die() function - not being able to disable them - not being able to define a constant named exit/die Maybe it would be wise to deprecate using exit as a statement to be able to get rid of the undefined constant magic handling. Anyhoot, before I spend more time on this and write a proper RFC, do people think this is a good idea or not? Best regards, Gina P. Banyard Hi Gina, I'm not sure a pet-peeve is a good motivation for creating an (I expect large) breaking change. The upgrade path, I suppose, would be updating calls to `die`/`exit` to always have parentheses ? Or alternatively changing those calls to new throw expressions ? While that shouldn't be that huge a problem for real codebases (and would be auto-fixable for adding the parentheses), the bigger problem I see is the huge amount of teaching materials, tutorials and blog posts using the versions without parentheses which will now all be invalidated. I think the pain and confusion that will cause for a change like this, will linger for years and years. Smile, Juliette
[PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
Hello internals, I've been having this mild annoyance with exit()/die() since I wrote a CLI script using a boolean $hasErrors variable to know if the script failed or not and to indicate if the script failed via a non-zero status code by doing: exit($hasErrors); However, it turns this doesn't work, because exit() will cast everything that is not an integer to a string, something that I find surprising but also weird as it will not type error on resources or array but rather print the warning to the CLI. Anyway, yesterday I decided to put on my mad scientist lab coat and make this a reality, I have a W.I.P. PR here: https://github.com/php/php-src/pull/13483 I hear you, but what about exit; ?! Do not worry exit; is still supported! It only requires a _tiny_ bit of dark magic to achieve this! exit; would just be interpreted as a fetch to a constant, so when attempting to access the undefined exit/die case-insensitive constant we just need to exit as if we were calling the function! Having exit and die be functions gives us access to some interesting functionality, such as defining exit() in a namespace, or removing it via the disable_functions INI setting (the latter allowing us to define a custom global exit() which could be useful for testing that a function actually calls exit). We can also pass it like any other callable and reflect on it with reflection. Finally, this removes the T_EXIT token and ZEND_EXIT opcode freeing one slot. The W.I.P. PR implement every possible restriction: - not being able to declare an exit()/die() function - not being able to disable them - not being able to define a constant named exit/die Maybe it would be wise to deprecate using exit as a statement to be able to get rid of the undefined constant magic handling. Anyhoot, before I spend more time on this and write a proper RFC, do people think this is a good idea or not? Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Fri, Feb 23, 2024, at 4:50 PM, Stephen Reay wrote:
>> On 23 Feb 2024, at 22:58, Larry Garfield wrote:
>>
>> On Fri, Feb 23, 2024, at 8:33 AM, Stephen Reay wrote:
On 23 Feb 2024, at 06:56, Larry Garfield wrote:
>>
>>> Hi Larry,
>>>
>>> It's good to see this idea still progressing.
>>>
>>>
>>> I have to agree with the other comment(s) that the implicit
>>> `$field`/`$value` variables seem odd to me. I understand the desire for
>>> brevity and the potential future scope of reused hooks, but this
>>> concept seems to fly in the face of many years of PHP reducing "magic"
>>> like this.
>>
>> The "magic" that PHP has been removing is mostly weird and illogical type
>> casting. As noted, neither of these variables are any more "magic" than
>> $this.
>>
>> However, since it seems no one likes $field, we have removed it from the
>> RFC. Of note, to respond to your comment further down,
>> $this->{__PROPERTY__} will not work. The virtual-property detection looks
>> for the AST representation of $this->propName, and only that. Dynamic
>> versions that turn into that at runtime cannot work, as it needs to be known
>> at compile time.
>>
>
> I guess it's mostly irrelevant on single-use hooks anyway, but that
> sounds like a potential gotcha with reusable hooks, and I think it's
> worth making it very clear *now* in the RFC/docs that dynamic access
> like this won't work as expected (and why). Perhaps some other
> indicator on reusablele hooks can be used at that point, to signify if
> it's virtual or not.
Look, we can have a common variable that can be used in all hooks, or we can
minimize the "magic" names. We can't do both. Make up your mind. :-P
It's already been included in the RFC that only explicit property name usage
will work.
As noted, reusable hook "packages" a la Swift is a potential future scope. At
that point having some common variable name is probably sensible, but we can
color that bikeshed when we get to it.
>> For $value, however, we feel strongly that having the default there is a
>> necessary part of the ergonomic picture. In particular, given your comments
>> here:
>> public function __construct(
>>public string $phone { set(string $phone) => $this->phone =
>> $this->sanitizePhone($phone); }
>>public string $phone { set => $this->sanitizePhone($value); }
>> ) {}
>>
>> Again, it's absolutely no contest for me. I would detest writing the longer
>> version every time.
>>
>
> I think you're making slightly misleading comparisons there, by picking
> the two extremes (and ignoring the possibly for shorter explicit names)
> - the explicit parameter name surely doesn't preclude the use of
> return-to-set functionality? So the comparison could equally be:
>
> ```
> public function __construct(
> public string $phone { set => $this->sanitizePhone($value); }
> public string $phone { set(string $v) => $this->sanitizePhone($v); }
> ){}
>
> ```
Yet nearly all coding standards and recommendations (outside of Go) say to not
use single-character variable names, so I wouldn't expect that to be common.
Even if it's not as big of a difference, it's still two places to specify the
type and two places to specify the variable name. That is, two places to get
either one wrong. Constructor Promotion is one of the best features of PHP 8,
precisely because it eliminates that kind of duplication. I see no reason to
mandate redundancy and duplication in code.
>> If PHP has been moving away from weird and inexplicable magic, it's also
>> been moving away from needless boilerplate. (Constructor promotion being
>> the best example, but not the only; types themselves are a factor here, as
>> are arrow functions.) As the whole point of this RFC is to make writing
>> common code easier, requiring redundant boilerplate for it to work is
>> actively counter-productive.
>>
>> So what I'd suggest instead is "specify the full signature if you want a
>> custom name OR wider type; or omit the param list entirely to get a
>> same-type $value variable, which 99% of the time is all you need." We get
>> that in return for documenting "$value is the default", which for someone
>> who has already figured out $this, should be a very low effort to learn.
>
> I get your point, and to expand on what I said in the first email - if
> removing the implicit mode would mean people vote against the RFC, then
> that's a worse result, IMO (this is why I suggest a secondary vote -
> perfect is th enemy of good and all that). I personally think the
> implicit variables will result in less-readable code, but I also know
> that I'm free to not use the implicit parameter in code that I write,
> so I trust those with a more accurate finger on the pulse of the voters
> to know whether the implicit `$value` parameter will help or hinder the
> RFC to pass.
As has been noted numerous times, there is basically zero way to tell what
people will vote
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Fri, Feb 23, 2024, at 5:35 PM, Marc Bennewitz wrote:
> Hi Larry,
>
> first of all thank you very much for this amazing work you two have been
> done :+1:.
> I'm also feeling that introducing magic variables isn't the best design
> choice.
> I read your section about "Why do set hooks not return the value to
> set?" and I don't really agree.
>
> Let me explain ...
>
> 1. Virtual properties and technically all functions return a valid.
>
> I think it would me much less magic if property setters on virtual
> properties declare a void return type.
> This would make it very obvious that this is a virtual property even on
> having to read complex setters.
Making everyone type ": void" after every set hook, when we already know that's
going to be the case, seems like a really bad developer experience.
I talked with Ilija extensively about it, and there is no meaningful way to
distinguish between "this method returned null" and "this method didn't return"
from the call site in the engine. If we could, that would allow smarter
detection of when it makes sense to use a return value. Hence my suggestion of
allowing set-on-return only for the => form.
> 3. ambiguity
>
> I actually feel that $field is ambiguous. What happens if you declare
> `set($field) {}` ? Does such construct let the engine set the property
> value immediately as the input value gets immediately assigned to the
> property via $field?
$field has already been removed. See previous email.
--Larry Garfield
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Hi Larry,
first of all thank you very much for this amazing work you two have been
done :+1:.
On 23.02.24 00:56, Larry Garfield wrote:
On Wed, Feb 21, 2024, at 11:02 PM, Matthew Weier O'Phinney wrote:
On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield wrote:
After much on-again/off-again work, Ilija and I are back with a more polished
property access hooks/interface properties RFC. It’s 99% unchanged from last
summer; the PR is now essentially complete and more robust, and we were able to
squish the last remaining edge cases.
Baring any major changes, we plan to bring this to a vote in mid-March.
https://wiki.php.net/rfc/property-hooks
It’s long, but that’s because we’re handling every edge case we could think of.
Properties involve dealing with both references and inheritance, both of which
have complex implications. We believe we’ve identified the most logical
handling for all cases, though.
Once again in reading the proposal, the first thing I'm struck by are
the magic "$field" and "$value" variables inside accessors. The first
time they are used, they're used without explanation, and they're
jarring.
Additionally, once you start defining the behavior of accessors... you
don't start with the basics, but instead jump into some of the more
esoteric usage, which does nothing to help with the questions I have.
So, first:
- Start with the most basic, most expected usage for each of reading
and writing properties.
- I need a better argument for why the $field and $value variables
exist. Saying they're macros doesn't help those not deep into
internals. As a user, why do they exist?
For $field, it's not a requirement. It's mostly for copy-paste convenience. A
number of people have struggled on this point so if the consensus is to leave out
$field and just use $this->propName directly, we can accept that. They can be
re-added if reusable hook packages are added in the future (as noted in Future
Scope).
I'm also feeling that introducing magic variables isn't the best design
choice.
I read your section about "Why do set hooks not return the value to
set?" and I don't really agree.
Let me explain ...
1. Virtual properties and technically all functions return a valid.
I think it would me much less magic if property setters on virtual
properties declare a void return type.
This would make it very obvious that this is a virtual property even on
having to read complex setters.
2. it disallows any action /after/ the assignment happens
I actually think this would be a good think!
An object property should only be set after everything has been done.
If you want to do more it should either not be part of the setter or you
should use a temporary variable what you have to do anyway to not leave
your object in an incorrect state.
Let's say we have the following setter:
public string$name {
set($value){ // do stuff
$field = $value; // or $this->name = $value
// do more stuff and (eventually) fail
throw Exception();
}
}
try {
$object->name = 'test';
} finally {
$object->name; // what is name here ?
}
3. ambiguity
I actually feel that $field is ambiguous. What happens if you declare
`set($field) {}` ? Does such construct let the engine set the property
value immediately as the input value gets immediately assigned to the
property via $field?
Greetings,
Marc
OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
> On 23 Feb 2024, at 22:58, Larry Garfield wrote:
>
> On Fri, Feb 23, 2024, at 8:33 AM, Stephen Reay wrote:
>>> On 23 Feb 2024, at 06:56, Larry Garfield wrote:
>
>> Hi Larry,
>> It's good to see this idea still progressing.
>> I have to agree with the other comment(s) that the implicit
>> `$field`/`$value` variables seem odd to me. I understand the desire for
>> brevity and the potential future scope of reused hooks, but this
>> concept seems to fly in the face of many years of PHP reducing "magic"
>> like this.
>
> The "magic" that PHP has been removing is mostly weird and illogical type
> casting. As noted, neither of these variables are any more "magic" than
> $this.
>
> However, since it seems no one likes $field, we have removed it from the RFC.
> Of note, to respond to your comment further down, $this->{__PROPERTY__} will
> not work. The virtual-property detection looks for the AST representation of
> $this->propName, and only that. Dynamic versions that turn into that at
> runtime cannot work, as it needs to be known at compile time.
I guess it's mostly irrelevant on single-use hooks anyway, but that sounds like
a potential gotcha with reusable hooks, and I think it's worth making it very
clear *now* in the RFC/docs that dynamic access like this won't work as
expected (and why). Perhaps some other indicator on reusablele hooks can be
used at that point, to signify if it's virtual or not.
> For $value, however, we feel strongly that having the default there is a
> necessary part of the ergonomic picture. In particular, given your comments
> here:
>
>> To give one answer to your question about ambiguity if the `$value`
>> parameter is required - I don't believe this is actually ambiguous, in
>> the context of PHP:
>> - method parameters in child classes don't implicitly 'inherit' the
>> parent method parameter's type if they don't define one (they widen to
>> mixed);
>> - method return types have no implicit inheritance, they must declare a
>> compatible return type;
>> - typed class properties don't implicitly inherit the parent type when
>> the type left off a child property - they must declare the same type.
>> AFAIK there is no existing behaviour in PHP where omitting a type would
>> mean "the type is implicitly inherited from X", it either means the
>> same as mixed, or it's an error.
>
> That to me suggests that IF a custom variable name is provided, we should
> require also specifying the type. In which case, in the 95% case, if we
> require the full argument signature then the 95% case would need to
> double-specify the type, which is a hard-no from an ergonomic standpoint.
>
> Especially combined with the suggestion yesterday to allow return-to-set in
> the short-set version, that would mean comparing this:
>
> public string $phone {
> set(string $phone) => $this->phone = $this->sanitizePhone($phone);
> }
>
> To this:
>
> public string $phone {
> set => $this->sanitizePhone($value);
> }
>
> And to me, there's absolutely no contest. The latter has about 1/3 as many
> places for me to make a typo repeating the same information over again. Now
> imagine comparing the above in a property that's used with constructor
> promotion.
>
>
> public function __construct(
> public string $phone { set(string $phone) => $this->phone =
> $this->sanitizePhone($phone); }
> public string $phone { set => $this->sanitizePhone($value); }
> ) {}
>
> Again, it's absolutely no contest for me. I would detest writing the longer
> version every time.
I think you're making slightly misleading comparisons there, by picking the two
extremes (and ignoring the possibly for shorter explicit names) - the explicit
parameter name surely doesn't preclude the use of return-to-set functionality?
So the comparison could equally be:
```
public function __construct(
public string $phone { set => $this->sanitizePhone($value); }
public string $phone { set(string $v) => $this->sanitizePhone($v); }
){}
```
> If PHP has been moving away from weird and inexplicable magic, it's also been
> moving away from needless boilerplate. (Constructor promotion being the best
> example, but not the only; types themselves are a factor here, as are arrow
> functions.) As the whole point of this RFC is to make writing common code
> easier, requiring redundant boilerplate for it to work is actively
> counter-productive.
>
> So what I'd suggest instead is "specify the full signature if you want a
> custom name OR wider type; or omit the param list entirely to get a same-type
> $value variable, which 99% of the time is all you need." We get that in
> return for documenting "$value is the default", which for someone who has
> already figured out $this, should be a very low effort to learn.
I get your point, and to expand on what I said in the first email - if removing
the implicit mode would mean people vote against the RFC, then that's a worse
result, IMO (this is why I
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Fri, Feb 23, 2024, at 8:33 AM, Stephen Reay wrote:
>> On 23 Feb 2024, at 06:56, Larry Garfield wrote:
> Hi Larry,
>
> It's good to see this idea still progressing.
>
>
> I have to agree with the other comment(s) that the implicit
> `$field`/`$value` variables seem odd to me. I understand the desire for
> brevity and the potential future scope of reused hooks, but this
> concept seems to fly in the face of many years of PHP reducing "magic"
> like this.
The "magic" that PHP has been removing is mostly weird and illogical type
casting. As noted, neither of these variables are any more "magic" than $this.
However, since it seems no one likes $field, we have removed it from the RFC.
Of note, to respond to your comment further down, $this->{__PROPERTY__} will
not work. The virtual-property detection looks for the AST representation of
$this->propName, and only that. Dynamic versions that turn into that at
runtime cannot work, as it needs to be known at compile time.
For $value, however, we feel strongly that having the default there is a
necessary part of the ergonomic picture. In particular, given your comments
here:
> To give one answer to your question about ambiguity if the `$value`
> parameter is required - I don't believe this is actually ambiguous, in
> the context of PHP:
> - method parameters in child classes don't implicitly 'inherit' the
> parent method parameter's type if they don't define one (they widen to
> mixed);
> - method return types have no implicit inheritance, they must declare a
> compatible return type;
> - typed class properties don't implicitly inherit the parent type when
> the type left off a child property - they must declare the same type.
>
> AFAIK there is no existing behaviour in PHP where omitting a type would
> mean "the type is implicitly inherited from X", it either means the
> same as mixed, or it's an error.
That to me suggests that IF a custom variable name is provided, we should
require also specifying the type. In which case, in the 95% case, if we
require the full argument signature then the 95% case would need to
double-specify the type, which is a hard-no from an ergonomic standpoint.
Especially combined with the suggestion yesterday to allow return-to-set in the
short-set version, that would mean comparing this:
public string $phone {
set(string $phone) => $this->phone = $this->sanitizePhone($phone);
}
To this:
public string $phone {
set => $this->sanitizePhone($value);
}
And to me, there's absolutely no contest. The latter has about 1/3 as many
places for me to make a typo repeating the same information over again. Now
imagine comparing the above in a property that's used with constructor
promotion.
public function __construct(
public string $phone { set(string $phone) => $this->phone =
$this->sanitizePhone($phone); }
public string $phone { set => $this->sanitizePhone($value); }
) {}
Again, it's absolutely no contest for me. I would detest writing the longer
version every time.
If PHP has been moving away from weird and inexplicable magic, it's also been
moving away from needless boilerplate. (Constructor promotion being the best
example, but not the only; types themselves are a factor here, as are arrow
functions.) As the whole point of this RFC is to make writing common code
easier, requiring redundant boilerplate for it to work is actively
counter-productive.
So what I'd suggest instead is "specify the full signature if you want a custom
name OR wider type; or omit the param list entirely to get a same-type $value
variable, which 99% of the time is all you need." We get that in return for
documenting "$value is the default", which for someone who has already figured
out $this, should be a very low effort to learn.
> Also, a small nitpick: The link to your attributeutils repo in the
> examples page, is broken, and it would be nice to see a few examples
> showing the explicit version of the hooks.
Link fixed, thanks. What do you mean explicit version of the hooks?
--Larry Garfield
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
> On 23 Feb 2024, at 06:56, Larry Garfield wrote:
>
> On Wed, Feb 21, 2024, at 11:02 PM, Matthew Weier O'Phinney wrote:
>> On Wed, Feb 21, 2024 at 12:57 PM Larry Garfield
>> wrote:
>>> After much on-again/off-again work, Ilija and I are back with a more
>>> polished property access hooks/interface properties RFC. It’s 99%
>>> unchanged from last summer; the PR is now essentially complete and more
>>> robust, and we were able to squish the last remaining edge cases.
>>>
>>> Baring any major changes, we plan to bring this to a vote in mid-March.
>>>
>>> https://wiki.php.net/rfc/property-hooks
>>>
>>> It’s long, but that’s because we’re handling every edge case we could think
>>> of. Properties involve dealing with both references and inheritance, both
>>> of which have complex implications. We believe we’ve identified the most
>>> logical handling for all cases, though.
>>
>> Once again in reading the proposal, the first thing I'm struck by are
>> the magic "$field" and "$value" variables inside accessors. The first
>> time they are used, they're used without explanation, and they're
>> jarring.
>>
>> Additionally, once you start defining the behavior of accessors... you
>> don't start with the basics, but instead jump into some of the more
>> esoteric usage, which does nothing to help with the questions I have.
>>
>> So, first:
>>
>> - Start with the most basic, most expected usage for each of reading
>> and writing properties.
>> - I need a better argument for why the $field and $value variables
>> exist. Saying they're macros doesn't help those not deep into
>> internals. As a user, why do they exist?
>
> For $field, it's not a requirement. It's mostly for copy-paste convenience.
> A number of people have struggled on this point so if the consensus is to
> leave out $field and just use $this->propName directly, we can accept that.
> They can be re-added if reusable hook packages are added in the future (as
> noted in Future Scope).
>
> For $value, it's to avoid boilerplate. For the majority case, you'll be just
> operating on an individual value trivially. Checking it's range, or
> uppercasing it, or whatever. Requiring the developer to provide a name
> explicitly is just extra work; it's much the same as how PHP doesn't require
> you to pass $this as the first argument to a method explicitly, the way
> Python and Rust do. It's just understood that $this exists, and once you
> learn that it's obvious.
>
> On the occasions where you do want to specify an alternate name for some
> reason, or more likely you're providing a wider type, you can. But in the
> typical case it would just be one more thing for the dev to have to type out.
> This is especially true in what I expect to be a common case, which is
> promoted constructor arguments with an extra validator set hook on them.
>
> It also introduces some ambiguity. If I specify only the name, does that
> mean I'm widening the type to mixed? Or just that I'm omitting the name? If
> specifying the name is rare, that's not really a big deal. If it's required
> in every case, it's a confusion point in every case.
>
> In the interest of transparency. for comparison:
>
> * Kotlin appears to require an argument name, but by convention recommends
> using "value".
> * Swift makes it optional, with a default name of "newValue". (Same logic as
> in the RFC.)
> * C# ... as far as I can tell, doesn't support a custom name at all; it's
> always called "value", implicitly.
>
>> Second: you don't have examples of defining BOTH get and set OTHER than
>> when using expressions for both accessors or a mix. I'm actually
>> unclear what the syntax is when both are defined. Is there supposed to
>> be a `;` terminating each? Or a `,`? Or just an empty line? Again,
>> this is one of the more common scenarios. It needs to be covered early,
>> and clearly.
>
> ... huh. I thought we had one in there somewhere. I will add one, thanks.
> Though to clarify, there's no separator character.
>
> public string $foo {
>get {
>// ...
>}
>set {
>// ...
>}
> }
>
>> Third: the caveats around usage with arrays... give me pause. While I'm
>> personally trying to not use arrays as much as possible, a lot of code
>> I see or contribute to still does, and the fact that an array property
>> that uses a write accessor doesn't allow the same level of access as a
>> normal array property is something I see leading to a lot of confusion
>> and errors. I don't have a solution, but I worry that this one thing
>> alone could be enough to prevent the passage of the RFC.
>
> We completely agree that it's a suboptimal situation. But as explained, it
> is the way it is because it's not possible (as far as we can tell) to fully
> support hooks on array properties. If you can think of one, please share,
> because we'd love to make this part better. I don't like it either, but we
>
