Perhaps this is the same reason why we add "public" keyword, even though a member is implicitly public by default.
On 19 December 2017 at 12:34, Andreas Hennings <andr...@dqxtech.net> wrote: > I agree with Michael Kliewe. > When looking at code, I want to distinguish between: > - Developer forgot to add a type hint, or it was left out for legacy / > BC reasons. > - The function can really return various types, at least too many for > any more specific type hint. > > > On 19 December 2017 at 04:57, li...@rhsoft.net <li...@rhsoft.net> wrote: >> no, mixed is used in phpdoc comments to say "no type specified at all" when >> a param accepts anything and in case of "@return mixed" that it can return >> void, array, int..... > > I think "mixed" should not include "void". > A well-written method/function either has a return value or not. It it > is type-hinted as "mixed", then we should expect it to have a return > value. > > On 19 December 2017 at 08:06, Fleshgrinder <p...@fleshgrinder.com> wrote: >> What is really needed are `scalar`, `number`, union types, intersection >> types, and all that together with generics. > > I would like to see those too, but they are not mutually exclusive > with "mixed" and should rather be discussed separately. > > > > On 19 December 2017 at 11:01, Michael Kliewe <i...@phpgangsta.de> wrote: >> Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev: >>> >>>> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: >>>> https://wiki.php.net/rfc/mixed-typehint >>>> >>>> The purpose of this RFC is to introduce "mixed" typehint on language level >>>> to be used >>>> as a valid typehint. PHP currently forces users to not use any type in case >>>> the >>>> type is mixed/unclear. This makes code inconsistent and less explicit. With >>> I'm not sure what's the point of it. "mixed" means "any type". Not >>> writing a type means "any type". So why waste space and add something >>> that contributes nothing when everybody is already using the current >>> convention and the new one does not add anything at all? >> A "mixed" type hint says that it's really "mixed", and the developer who >> wrote that code did not forget to add a type hint. >> If you see a place where a type hint is missing, you don't know if it's >> mixed, or the developer/you missed to write the correct type hint. >> >> That's the benefit I see. I would explicitly write "mixed" everywhere in >> a fully type-hinted codebase, to eliminate this thought while reading: >> Is it really mixed, or was this place overseen and it's not mixed, but >> something else... >> Because it's optional, nobody is hurt, but some people (like me) could >> add this explicit information. >> >> Michael >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
