Re: [RFC] DocComments For Function Parameters

Am 24.02.2026 um 20:13 schrieb Larry Garfield <larry@garfieldtech.com>: > 1. As Matthew said, putting the doc comment after the parameter is inconsistent. I've... > never actually seen someone do that. I have seen people put doc comments on the line before a > parameter (which I then had to move to the function docblock, which was annoying). Every other > docblock-able construct has the docblock as a prefix, not suffix. It should be a prefix here as > well. Just to clarify: You can write it before, in the middle or after the parameter, just like you can write it before or in the middle of properties. The proposal allows pre, middle and post styles. I understand that putting it after the parameter is not to everybody's taste but is the fact that this proposal *allows* it to be after a deal-breaker? If people feel really strongly about not allowing this (but why didn't anyone ever complain about in-the-middle doccomments for properties etc. so far?) then I could adapt the proposal. I'm not yet convinced of the harm though. > 2. I realize the existing getDocComment() implementations also use string|false, but at what > point are we going to accept that is a stupid return type and use string|null instead? :-( (I > realize it may not be fixable here; I just want to whine about that design flaw propagating even > further.) I agree that anything|false is most of the time a mistake (as the absence of a value is better expressed by null) but I doubt we should change that for this single case only. If we want to change this then it should be a proposal for a whole range of functions, or in this case at least for getDocComment() in all Reflection classes. Regards, - Chris