Re: array coalesce operator concept

From: Date: Thu, 13 Jul 2017 07:01:32 +0000
Subject: Re: array coalesce operator concept
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-99867@lists.php.net to get a copy of this message
2017-07-12 22:14 GMT+02:00 Niklas Keller <me@kelunik.com>: > 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski < > michal.brzuchalski@gmail.com>: > >> 12.07.2017 15:35 "Mark Shust" <mark@shust.com> napisał(a): >> > >> > Hi Aidan, >> > >> > I think you are correct on all points. The initial emit is just a >> warning, >> > so I think a suppressor will work just fine, since it does just pass >> over >> > the foreach if a traversable isn't passed in. >> > >> > I could see this being helpful as it makes wrapping an if block around a >> > foreach not needed anymore (and in turn indenting the foreach another >> > level), replacing it with just a single character. I also think for >> those >> > that use linting tools and flag error suppressions, that an @as >> definition >> > could be easily ignored from such a linter. I develop with warnings on, >> and >> > see error suppressions as a sort of code smell, however I think the @as >> > definition could be really useful. >> >> IMHO the whole error supression and its operator should be deprecated and >> removed from language. Supressing errors is just hiding problems because >> someone didn't want to solve it. Supressing errors makes debuging very >> hard >> and leads to frustration. > > > You have to update a whole lot of APIs before you can do that. There are > many things where it's better to ignore the warning and check the return > value and throw an exception if something is wrong. > > Regards, Niklas > > Hi Niklas, could you name few of them? My ideal vision is catching thrown exceptions instead of suppressing errors.. BTW it would unlock '@' for future features like use for annotations/attributes. Regards, -- Michał Brzuchalski

« previous php.internals (#99867) next »