Issues (221)

Security Analysis    no request data  

This project does not seem to handle request data directly as such no vulnerable execution paths were found.

  Cross-Site Scripting
Cross-Site Scripting enables an attacker to inject code into the response of a web-request that is viewed by other users. It can for example be used to bypass access controls, or even to take over other users' accounts.
  File Exposure
File Exposure allows an attacker to gain access to local files that he should not be able to access. These files can for example include database credentials, or other configuration files.
  File Manipulation
File Manipulation enables an attacker to write custom data to files. This potentially leads to injection of arbitrary code on the server.
  Object Injection
Object Injection enables an attacker to inject an object into PHP code, and can lead to arbitrary code execution, file exposure, or file manipulation attacks.
  Code Injection
Code Injection enables an attacker to execute arbitrary code on the server.
  Response Splitting
Response Splitting can be used to send arbitrary responses.
  File Inclusion
File Inclusion enables an attacker to inject custom files into PHP's file loading mechanism, either explicitly passed to include, or for example via PHP's auto-loading mechanism.
  Command Injection
Command Injection enables an attacker to inject a shell command that is execute with the privileges of the web-server. This can be used to expose sensitive data, or gain access of your server.
  SQL Injection
SQL Injection enables an attacker to execute arbitrary SQL code on your database server gaining access to user data, or manipulating user data.
  XPath Injection
XPath Injection enables an attacker to modify the parts of XML document that are read. If that XML document is for example used for authentication, this can lead to further vulnerabilities similar to SQL Injection.
  LDAP Injection
LDAP Injection enables an attacker to inject LDAP statements potentially granting permission to run unauthorized queries, or modify content inside the LDAP tree.
  Header Injection
  Other Vulnerability
This category comprises other attack vectors such as manipulating the PHP runtime, loading custom extensions, freezing the runtime, or similar.
  Regex Injection
Regex Injection enables an attacker to execute arbitrary code in your PHP process.
  XML Injection
XML Injection enables an attacker to read files on your local filesystem including configuration files, or can be abused to freeze your web-server process.
  Variable Injection
Variable Injection enables an attacker to overwrite program variables with custom data, and can lead to further vulnerabilities.
Unfortunately, the security analysis is currently not available for your project. If you are a non-commercial open-source project, please contact support to gain access.

src/Mixin.php (217 issues)

Upgrade to new PHP Analysis Engine

These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more

1
<?php
2
3
/**
4
 * provides type inference and auto-completion for magic static methods of Assert.
5
 */
6
7
namespace Webmozart\Assert;
8
9
use ArrayAccess;
10
use Closure;
11
use Countable;
12
use InvalidArgumentException;
13
use Throwable;
14
15
interface Mixin
16
{
17
    /**
18
     * @psalm-pure
19
     * @psalm-assert string|null $value
20
     *
21
     * @param mixed  $value
22
     * @param string $message
23
     *
24
     * @throws InvalidArgumentException
25
     */
26
    public static function nullOrString($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
27
28
    /**
29
     * @psalm-pure
30
     * @psalm-assert iterable<string> $value
31
     *
32
     * @param mixed  $value
33
     * @param string $message
34
     *
35
     * @throws InvalidArgumentException
36
     */
37
    public static function allString($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
38
39
    /**
40
     * @psalm-pure
41
     * @psalm-assert non-empty-string|null $value
42
     *
43
     * @param mixed  $value
44
     * @param string $message
45
     *
46
     * @throws InvalidArgumentException
47
     */
48
    public static function nullOrStringNotEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
49
50
    /**
51
     * @psalm-pure
52
     * @psalm-assert iterable<non-empty-string> $value
53
     *
54
     * @param mixed  $value
55
     * @param string $message
56
     *
57
     * @throws InvalidArgumentException
58
     */
59
    public static function allStringNotEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
60
61
    /**
62
     * @psalm-pure
63
     * @psalm-assert int|null $value
64
     *
65
     * @param mixed  $value
66
     * @param string $message
67
     *
68
     * @throws InvalidArgumentException
69
     */
70
    public static function nullOrInteger($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
71
72
    /**
73
     * @psalm-pure
74
     * @psalm-assert iterable<int> $value
75
     *
76
     * @param mixed  $value
77
     * @param string $message
78
     *
79
     * @throws InvalidArgumentException
80
     */
81
    public static function allInteger($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
82
83
    /**
84
     * @psalm-pure
85
     * @psalm-assert numeric|null $value
86
     *
87
     * @param mixed  $value
88
     * @param string $message
89
     *
90
     * @throws InvalidArgumentException
91
     */
92
    public static function nullOrIntegerish($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
93
94
    /**
95
     * @psalm-pure
96
     * @psalm-assert iterable<numeric> $value
97
     *
98
     * @param mixed  $value
99
     * @param string $message
100
     *
101
     * @throws InvalidArgumentException
102
     */
103
    public static function allIntegerish($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
104
105
    /**
106
     * @psalm-pure
107
     * @psalm-assert float|null $value
108
     *
109
     * @param mixed  $value
110
     * @param string $message
111
     *
112
     * @throws InvalidArgumentException
113
     */
114
    public static function nullOrFloat($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
115
116
    /**
117
     * @psalm-pure
118
     * @psalm-assert iterable<float> $value
119
     *
120
     * @param mixed  $value
121
     * @param string $message
122
     *
123
     * @throws InvalidArgumentException
124
     */
125
    public static function allFloat($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
126
127
    /**
128
     * @psalm-pure
129
     * @psalm-assert numeric|null $value
130
     *
131
     * @param mixed  $value
132
     * @param string $message
133
     *
134
     * @throws InvalidArgumentException
135
     */
136
    public static function nullOrNumeric($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
137
138
    /**
139
     * @psalm-pure
140
     * @psalm-assert iterable<numeric> $value
141
     *
142
     * @param mixed  $value
143
     * @param string $message
144
     *
145
     * @throws InvalidArgumentException
146
     */
147
    public static function allNumeric($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
148
149
    /**
150
     * @psalm-pure
151
     * @psalm-assert int|null $value
152
     *
153
     * @param mixed  $value
154
     * @param string $message
155
     *
156
     * @throws InvalidArgumentException
157
     */
158
    public static function nullOrNatural($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
159
160
    /**
161
     * @psalm-pure
162
     * @psalm-assert iterable<int> $value
163
     *
164
     * @param mixed  $value
165
     * @param string $message
166
     *
167
     * @throws InvalidArgumentException
168
     */
169
    public static function allNatural($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
170
171
    /**
172
     * @psalm-pure
173
     * @psalm-assert bool|null $value
174
     *
175
     * @param mixed  $value
176
     * @param string $message
177
     *
178
     * @throws InvalidArgumentException
179
     */
180
    public static function nullOrBoolean($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
181
182
    /**
183
     * @psalm-pure
184
     * @psalm-assert iterable<bool> $value
185
     *
186
     * @param mixed  $value
187
     * @param string $message
188
     *
189
     * @throws InvalidArgumentException
190
     */
191
    public static function allBoolean($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
192
193
    /**
194
     * @psalm-pure
195
     * @psalm-assert scalar|null $value
196
     *
197
     * @param mixed  $value
198
     * @param string $message
199
     *
200
     * @throws InvalidArgumentException
201
     */
202
    public static function nullOrScalar($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
203
204
    /**
205
     * @psalm-pure
206
     * @psalm-assert iterable<scalar> $value
207
     *
208
     * @param mixed  $value
209
     * @param string $message
210
     *
211
     * @throws InvalidArgumentException
212
     */
213
    public static function allScalar($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
214
215
    /**
216
     * @psalm-pure
217
     * @psalm-assert object|null $value
218
     *
219
     * @param mixed  $value
220
     * @param string $message
221
     *
222
     * @throws InvalidArgumentException
223
     */
224
    public static function nullOrObject($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
225
226
    /**
227
     * @psalm-pure
228
     * @psalm-assert iterable<object> $value
229
     *
230
     * @param mixed  $value
231
     * @param string $message
232
     *
233
     * @throws InvalidArgumentException
234
     */
235
    public static function allObject($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
236
237
    /**
238
     * @psalm-pure
239
     * @psalm-assert resource|null $value
240
     *
241
     * @param mixed       $value
242
     * @param string|null $type    type of resource this should be. @see https://www.php.net/manual/en/function.get-resource-type.php
243
     * @param string      $message
244
     *
245
     * @throws InvalidArgumentException
246
     */
247
    public static function nullOrResource($value, $type = null, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
248
249
    /**
250
     * @psalm-pure
251
     * @psalm-assert iterable<resource> $value
252
     *
253
     * @param mixed       $value
254
     * @param string|null $type    type of resource this should be. @see https://www.php.net/manual/en/function.get-resource-type.php
255
     * @param string      $message
256
     *
257
     * @throws InvalidArgumentException
258
     */
259
    public static function allResource($value, $type = null, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
260
261
    /**
262
     * @psalm-pure
263
     * @psalm-assert callable|null $value
264
     *
265
     * @param mixed  $value
266
     * @param string $message
267
     *
268
     * @throws InvalidArgumentException
269
     */
270
    public static function nullOrIsCallable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
271
272
    /**
273
     * @psalm-pure
274
     * @psalm-assert iterable<callable> $value
275
     *
276
     * @param mixed  $value
277
     * @param string $message
278
     *
279
     * @throws InvalidArgumentException
280
     */
281
    public static function allIsCallable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
282
283
    /**
284
     * @psalm-pure
285
     * @psalm-assert array|null $value
286
     *
287
     * @param mixed  $value
288
     * @param string $message
289
     *
290
     * @throws InvalidArgumentException
291
     */
292
    public static function nullOrIsArray($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
293
294
    /**
295
     * @psalm-pure
296
     * @psalm-assert iterable<array> $value
297
     *
298
     * @param mixed  $value
299
     * @param string $message
300
     *
301
     * @throws InvalidArgumentException
302
     */
303
    public static function allIsArray($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
304
305
    /**
306
     * @psalm-pure
307
     * @psalm-assert iterable|null $value
308
     *
309
     * @deprecated use "isIterable" or "isInstanceOf" instead
310
     *
311
     * @param mixed  $value
312
     * @param string $message
313
     *
314
     * @throws InvalidArgumentException
315
     */
316
    public static function nullOrIsTraversable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
317
318
    /**
319
     * @psalm-pure
320
     * @psalm-assert iterable<iterable> $value
321
     *
322
     * @deprecated use "isIterable" or "isInstanceOf" instead
323
     *
324
     * @param mixed  $value
325
     * @param string $message
326
     *
327
     * @throws InvalidArgumentException
328
     */
329
    public static function allIsTraversable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
330
331
    /**
332
     * @psalm-pure
333
     * @psalm-assert array|ArrayAccess|null $value
334
     *
335
     * @param mixed  $value
336
     * @param string $message
337
     *
338
     * @throws InvalidArgumentException
339
     */
340
    public static function nullOrIsArrayAccessible($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
341
342
    /**
343
     * @psalm-pure
344
     * @psalm-assert iterable<array|ArrayAccess> $value
345
     *
346
     * @param mixed  $value
347
     * @param string $message
348
     *
349
     * @throws InvalidArgumentException
350
     */
351
    public static function allIsArrayAccessible($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
352
353
    /**
354
     * @psalm-pure
355
     * @psalm-assert countable|null $value
356
     *
357
     * @param mixed  $value
358
     * @param string $message
359
     *
360
     * @throws InvalidArgumentException
361
     */
362
    public static function nullOrIsCountable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
363
364
    /**
365
     * @psalm-pure
366
     * @psalm-assert iterable<countable> $value
367
     *
368
     * @param mixed  $value
369
     * @param string $message
370
     *
371
     * @throws InvalidArgumentException
372
     */
373
    public static function allIsCountable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
374
375
    /**
376
     * @psalm-pure
377
     * @psalm-assert iterable|null $value
378
     *
379
     * @param mixed  $value
380
     * @param string $message
381
     *
382
     * @throws InvalidArgumentException
383
     */
384
    public static function nullOrIsIterable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
385
386
    /**
387
     * @psalm-pure
388
     * @psalm-assert iterable<iterable> $value
389
     *
390
     * @param mixed  $value
391
     * @param string $message
392
     *
393
     * @throws InvalidArgumentException
394
     */
395
    public static function allIsIterable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
396
397
    /**
398
     * @psalm-pure
399
     * @psalm-template ExpectedType of object
400
     * @psalm-param class-string<ExpectedType> $class
401
     * @psalm-assert ExpectedType|null $value
402
     *
403
     * @param mixed         $value
404
     * @param string|object $class
405
     * @param string        $message
406
     *
407
     * @throws InvalidArgumentException
408
     */
409
    public static function nullOrIsInstanceOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
410
411
    /**
412
     * @psalm-pure
413
     * @psalm-template ExpectedType of object
414
     * @psalm-param class-string<ExpectedType> $class
415
     * @psalm-assert iterable<ExpectedType> $value
416
     *
417
     * @param mixed         $value
418
     * @param string|object $class
419
     * @param string        $message
420
     *
421
     * @throws InvalidArgumentException
422
     */
423
    public static function allIsInstanceOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
424
425
    /**
426
     * @psalm-pure
427
     * @psalm-template ExpectedType of object
428
     * @psalm-param class-string<ExpectedType> $class
429
     *
430
     * @param mixed         $value
431
     * @param string|object $class
432
     * @param string        $message
433
     *
434
     * @throws InvalidArgumentException
435
     */
436
    public static function nullOrNotInstanceOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
437
438
    /**
439
     * @psalm-pure
440
     * @psalm-template ExpectedType of object
441
     * @psalm-param class-string<ExpectedType> $class
442
     *
443
     * @param mixed         $value
444
     * @param string|object $class
445
     * @param string        $message
446
     *
447
     * @throws InvalidArgumentException
448
     */
449
    public static function allNotInstanceOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
450
451
    /**
452
     * @psalm-pure
453
     * @psalm-param array<class-string> $classes
454
     *
455
     * @param mixed                $value
456
     * @param array<object|string> $classes
457
     * @param string               $message
458
     *
459
     * @throws InvalidArgumentException
460
     */
461
    public static function nullOrIsInstanceOfAny($value, $classes, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
462
463
    /**
464
     * @psalm-pure
465
     * @psalm-param array<class-string> $classes
466
     *
467
     * @param mixed                $value
468
     * @param array<object|string> $classes
469
     * @param string               $message
470
     *
471
     * @throws InvalidArgumentException
472
     */
473
    public static function allIsInstanceOfAny($value, $classes, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
474
475
    /**
476
     * @psalm-pure
477
     * @psalm-template ExpectedType of object
478
     * @psalm-param class-string<ExpectedType> $class
479
     * @psalm-assert ExpectedType|class-string<ExpectedType>|null $value
480
     *
481
     * @param object|string|null $value
482
     * @param string             $class
483
     * @param string             $message
484
     *
485
     * @throws InvalidArgumentException
486
     */
487
    public static function nullOrIsAOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
488
489
    /**
490
     * @psalm-pure
491
     * @psalm-template ExpectedType of object
492
     * @psalm-param class-string<ExpectedType> $class
493
     * @psalm-assert iterable<ExpectedType|class-string<ExpectedType>> $value
494
     *
495
     * @param iterable<object|string> $value
0 ignored issues
show
The doc-type iterable<object|string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
496
     * @param string                  $class
497
     * @param string                  $message
498
     *
499
     * @throws InvalidArgumentException
500
     */
501
    public static function allIsAOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
502
503
    /**
504
     * @psalm-pure
505
     * @psalm-template UnexpectedType of object
506
     * @psalm-param class-string<UnexpectedType> $class
507
     *
508
     * @param object|string|null $value
509
     * @param string             $class
510
     * @param string             $message
511
     *
512
     * @throws InvalidArgumentException
513
     */
514
    public static function nullOrIsNotA($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
515
516
    /**
517
     * @psalm-pure
518
     * @psalm-template UnexpectedType of object
519
     * @psalm-param class-string<UnexpectedType> $class
520
     *
521
     * @param iterable<object|string> $value
0 ignored issues
show
The doc-type iterable<object|string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
522
     * @param string                  $class
523
     * @param string                  $message
524
     *
525
     * @throws InvalidArgumentException
526
     */
527
    public static function allIsNotA($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
528
529
    /**
530
     * @psalm-pure
531
     * @psalm-param array<class-string> $classes
532
     *
533
     * @param object|string|null $value
534
     * @param string[]           $classes
535
     * @param string             $message
536
     *
537
     * @throws InvalidArgumentException
538
     */
539
    public static function nullOrIsAnyOf($value, $classes, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
540
541
    /**
542
     * @psalm-pure
543
     * @psalm-param array<class-string> $classes
544
     *
545
     * @param iterable<object|string> $value
0 ignored issues
show
The doc-type iterable<object|string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
546
     * @param string[]                $classes
547
     * @param string                  $message
548
     *
549
     * @throws InvalidArgumentException
550
     */
551
    public static function allIsAnyOf($value, $classes, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
552
553
    /**
554
     * @psalm-pure
555
     * @psalm-assert empty $value
556
     *
557
     * @param mixed  $value
558
     * @param string $message
559
     *
560
     * @throws InvalidArgumentException
561
     */
562
    public static function nullOrIsEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
563
564
    /**
565
     * @psalm-pure
566
     * @psalm-assert iterable<empty> $value
567
     *
568
     * @param mixed  $value
569
     * @param string $message
570
     *
571
     * @throws InvalidArgumentException
572
     */
573
    public static function allIsEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
574
575
    /**
576
     * @psalm-pure
577
     *
578
     * @param mixed  $value
579
     * @param string $message
580
     *
581
     * @throws InvalidArgumentException
582
     */
583
    public static function nullOrNotEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
584
585
    /**
586
     * @psalm-pure
587
     *
588
     * @param mixed  $value
589
     * @param string $message
590
     *
591
     * @throws InvalidArgumentException
592
     */
593
    public static function allNotEmpty($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
594
595
    /**
596
     * @psalm-pure
597
     * @psalm-assert iterable<null> $value
598
     *
599
     * @param mixed  $value
600
     * @param string $message
601
     *
602
     * @throws InvalidArgumentException
603
     */
604
    public static function allNull($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
605
606
    /**
607
     * @psalm-pure
608
     *
609
     * @param mixed  $value
610
     * @param string $message
611
     *
612
     * @throws InvalidArgumentException
613
     */
614
    public static function allNotNull($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
615
616
    /**
617
     * @psalm-pure
618
     * @psalm-assert true|null $value
619
     *
620
     * @param mixed  $value
621
     * @param string $message
622
     *
623
     * @throws InvalidArgumentException
624
     */
625
    public static function nullOrTrue($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
626
627
    /**
628
     * @psalm-pure
629
     * @psalm-assert iterable<true> $value
630
     *
631
     * @param mixed  $value
632
     * @param string $message
633
     *
634
     * @throws InvalidArgumentException
635
     */
636
    public static function allTrue($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
637
638
    /**
639
     * @psalm-pure
640
     * @psalm-assert false|null $value
641
     *
642
     * @param mixed  $value
643
     * @param string $message
644
     *
645
     * @throws InvalidArgumentException
646
     */
647
    public static function nullOrFalse($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
648
649
    /**
650
     * @psalm-pure
651
     * @psalm-assert iterable<false> $value
652
     *
653
     * @param mixed  $value
654
     * @param string $message
655
     *
656
     * @throws InvalidArgumentException
657
     */
658
    public static function allFalse($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
659
660
    /**
661
     * @psalm-pure
662
     *
663
     * @param mixed  $value
664
     * @param string $message
665
     *
666
     * @throws InvalidArgumentException
667
     */
668
    public static function nullOrNotFalse($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
669
670
    /**
671
     * @psalm-pure
672
     *
673
     * @param mixed  $value
674
     * @param string $message
675
     *
676
     * @throws InvalidArgumentException
677
     */
678
    public static function allNotFalse($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
679
680
    /**
681
     * @param mixed  $value
682
     * @param string $message
683
     *
684
     * @throws InvalidArgumentException
685
     */
686
    public static function nullOrIp($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
687
688
    /**
689
     * @param mixed  $value
690
     * @param string $message
691
     *
692
     * @throws InvalidArgumentException
693
     */
694
    public static function allIp($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
695
696
    /**
697
     * @param mixed  $value
698
     * @param string $message
699
     *
700
     * @throws InvalidArgumentException
701
     */
702
    public static function nullOrIpv4($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
703
704
    /**
705
     * @param mixed  $value
706
     * @param string $message
707
     *
708
     * @throws InvalidArgumentException
709
     */
710
    public static function allIpv4($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
711
712
    /**
713
     * @param mixed  $value
714
     * @param string $message
715
     *
716
     * @throws InvalidArgumentException
717
     */
718
    public static function nullOrIpv6($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
719
720
    /**
721
     * @param mixed  $value
722
     * @param string $message
723
     *
724
     * @throws InvalidArgumentException
725
     */
726
    public static function allIpv6($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
727
728
    /**
729
     * @param mixed  $value
730
     * @param string $message
731
     *
732
     * @throws InvalidArgumentException
733
     */
734
    public static function nullOrEmail($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
735
736
    /**
737
     * @param mixed  $value
738
     * @param string $message
739
     *
740
     * @throws InvalidArgumentException
741
     */
742
    public static function allEmail($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
743
744
    /**
745
     * @param array|null $values
746
     * @param string     $message
747
     *
748
     * @throws InvalidArgumentException
749
     */
750
    public static function nullOrUniqueValues($values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
751
752
    /**
753
     * @param iterable<array> $values
0 ignored issues
show
The doc-type iterable<array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
754
     * @param string          $message
755
     *
756
     * @throws InvalidArgumentException
757
     */
758
    public static function allUniqueValues($values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
759
760
    /**
761
     * @param mixed  $value
762
     * @param mixed  $expect
763
     * @param string $message
764
     *
765
     * @throws InvalidArgumentException
766
     */
767
    public static function nullOrEq($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
768
769
    /**
770
     * @param mixed  $value
771
     * @param mixed  $expect
772
     * @param string $message
773
     *
774
     * @throws InvalidArgumentException
775
     */
776
    public static function allEq($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
777
778
    /**
779
     * @param mixed  $value
780
     * @param mixed  $expect
781
     * @param string $message
782
     *
783
     * @throws InvalidArgumentException
784
     */
785
    public static function nullOrNotEq($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
786
787
    /**
788
     * @param mixed  $value
789
     * @param mixed  $expect
790
     * @param string $message
791
     *
792
     * @throws InvalidArgumentException
793
     */
794
    public static function allNotEq($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
795
796
    /**
797
     * @psalm-pure
798
     *
799
     * @param mixed  $value
800
     * @param mixed  $expect
801
     * @param string $message
802
     *
803
     * @throws InvalidArgumentException
804
     */
805
    public static function nullOrSame($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
806
807
    /**
808
     * @psalm-pure
809
     *
810
     * @param mixed  $value
811
     * @param mixed  $expect
812
     * @param string $message
813
     *
814
     * @throws InvalidArgumentException
815
     */
816
    public static function allSame($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
817
818
    /**
819
     * @psalm-pure
820
     *
821
     * @param mixed  $value
822
     * @param mixed  $expect
823
     * @param string $message
824
     *
825
     * @throws InvalidArgumentException
826
     */
827
    public static function nullOrNotSame($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
828
829
    /**
830
     * @psalm-pure
831
     *
832
     * @param mixed  $value
833
     * @param mixed  $expect
834
     * @param string $message
835
     *
836
     * @throws InvalidArgumentException
837
     */
838
    public static function allNotSame($value, $expect, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
839
840
    /**
841
     * @psalm-pure
842
     *
843
     * @param mixed  $value
844
     * @param mixed  $limit
845
     * @param string $message
846
     *
847
     * @throws InvalidArgumentException
848
     */
849
    public static function nullOrGreaterThan($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
850
851
    /**
852
     * @psalm-pure
853
     *
854
     * @param mixed  $value
855
     * @param mixed  $limit
856
     * @param string $message
857
     *
858
     * @throws InvalidArgumentException
859
     */
860
    public static function allGreaterThan($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
861
862
    /**
863
     * @psalm-pure
864
     *
865
     * @param mixed  $value
866
     * @param mixed  $limit
867
     * @param string $message
868
     *
869
     * @throws InvalidArgumentException
870
     */
871
    public static function nullOrGreaterThanEq($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
872
873
    /**
874
     * @psalm-pure
875
     *
876
     * @param mixed  $value
877
     * @param mixed  $limit
878
     * @param string $message
879
     *
880
     * @throws InvalidArgumentException
881
     */
882
    public static function allGreaterThanEq($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
883
884
    /**
885
     * @psalm-pure
886
     *
887
     * @param mixed  $value
888
     * @param mixed  $limit
889
     * @param string $message
890
     *
891
     * @throws InvalidArgumentException
892
     */
893
    public static function nullOrLessThan($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
894
895
    /**
896
     * @psalm-pure
897
     *
898
     * @param mixed  $value
899
     * @param mixed  $limit
900
     * @param string $message
901
     *
902
     * @throws InvalidArgumentException
903
     */
904
    public static function allLessThan($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
905
906
    /**
907
     * @psalm-pure
908
     *
909
     * @param mixed  $value
910
     * @param mixed  $limit
911
     * @param string $message
912
     *
913
     * @throws InvalidArgumentException
914
     */
915
    public static function nullOrLessThanEq($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
916
917
    /**
918
     * @psalm-pure
919
     *
920
     * @param mixed  $value
921
     * @param mixed  $limit
922
     * @param string $message
923
     *
924
     * @throws InvalidArgumentException
925
     */
926
    public static function allLessThanEq($value, $limit, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
927
928
    /**
929
     * @psalm-pure
930
     *
931
     * @param mixed  $value
932
     * @param mixed  $min
933
     * @param mixed  $max
934
     * @param string $message
935
     *
936
     * @throws InvalidArgumentException
937
     */
938
    public static function nullOrRange($value, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
939
940
    /**
941
     * @psalm-pure
942
     *
943
     * @param mixed  $value
944
     * @param mixed  $min
945
     * @param mixed  $max
946
     * @param string $message
947
     *
948
     * @throws InvalidArgumentException
949
     */
950
    public static function allRange($value, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
951
952
    /**
953
     * @psalm-pure
954
     *
955
     * @param mixed  $value
956
     * @param array  $values
957
     * @param string $message
958
     *
959
     * @throws InvalidArgumentException
960
     */
961
    public static function nullOrOneOf($value, $values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
962
963
    /**
964
     * @psalm-pure
965
     *
966
     * @param mixed  $value
967
     * @param array  $values
968
     * @param string $message
969
     *
970
     * @throws InvalidArgumentException
971
     */
972
    public static function allOneOf($value, $values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
973
974
    /**
975
     * @psalm-pure
976
     *
977
     * @param mixed  $value
978
     * @param array  $values
979
     * @param string $message
980
     *
981
     * @throws InvalidArgumentException
982
     */
983
    public static function nullOrInArray($value, $values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
984
985
    /**
986
     * @psalm-pure
987
     *
988
     * @param mixed  $value
989
     * @param array  $values
990
     * @param string $message
991
     *
992
     * @throws InvalidArgumentException
993
     */
994
    public static function allInArray($value, $values, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
995
996
    /**
997
     * @psalm-pure
998
     *
999
     * @param string|null $value
1000
     * @param string      $subString
1001
     * @param string      $message
1002
     *
1003
     * @throws InvalidArgumentException
1004
     */
1005
    public static function nullOrContains($value, $subString, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1006
1007
    /**
1008
     * @psalm-pure
1009
     *
1010
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1011
     * @param string           $subString
1012
     * @param string           $message
1013
     *
1014
     * @throws InvalidArgumentException
1015
     */
1016
    public static function allContains($value, $subString, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1017
1018
    /**
1019
     * @psalm-pure
1020
     *
1021
     * @param string|null $value
1022
     * @param string      $subString
1023
     * @param string      $message
1024
     *
1025
     * @throws InvalidArgumentException
1026
     */
1027
    public static function nullOrNotContains($value, $subString, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1028
1029
    /**
1030
     * @psalm-pure
1031
     *
1032
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1033
     * @param string           $subString
1034
     * @param string           $message
1035
     *
1036
     * @throws InvalidArgumentException
1037
     */
1038
    public static function allNotContains($value, $subString, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1039
1040
    /**
1041
     * @psalm-pure
1042
     *
1043
     * @param string|null $value
1044
     * @param string      $message
1045
     *
1046
     * @throws InvalidArgumentException
1047
     */
1048
    public static function nullOrNotWhitespaceOnly($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1049
1050
    /**
1051
     * @psalm-pure
1052
     *
1053
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1054
     * @param string           $message
1055
     *
1056
     * @throws InvalidArgumentException
1057
     */
1058
    public static function allNotWhitespaceOnly($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1059
1060
    /**
1061
     * @psalm-pure
1062
     *
1063
     * @param string|null $value
1064
     * @param string      $prefix
1065
     * @param string      $message
1066
     *
1067
     * @throws InvalidArgumentException
1068
     */
1069
    public static function nullOrStartsWith($value, $prefix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1070
1071
    /**
1072
     * @psalm-pure
1073
     *
1074
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1075
     * @param string           $prefix
1076
     * @param string           $message
1077
     *
1078
     * @throws InvalidArgumentException
1079
     */
1080
    public static function allStartsWith($value, $prefix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1081
1082
    /**
1083
     * @psalm-pure
1084
     *
1085
     * @param string|null $value
1086
     * @param string      $prefix
1087
     * @param string      $message
1088
     *
1089
     * @throws InvalidArgumentException
1090
     */
1091
    public static function nullOrNotStartsWith($value, $prefix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1092
1093
    /**
1094
     * @psalm-pure
1095
     *
1096
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1097
     * @param string           $prefix
1098
     * @param string           $message
1099
     *
1100
     * @throws InvalidArgumentException
1101
     */
1102
    public static function allNotStartsWith($value, $prefix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1103
1104
    /**
1105
     * @psalm-pure
1106
     *
1107
     * @param mixed  $value
1108
     * @param string $message
1109
     *
1110
     * @throws InvalidArgumentException
1111
     */
1112
    public static function nullOrStartsWithLetter($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1113
1114
    /**
1115
     * @psalm-pure
1116
     *
1117
     * @param mixed  $value
1118
     * @param string $message
1119
     *
1120
     * @throws InvalidArgumentException
1121
     */
1122
    public static function allStartsWithLetter($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1123
1124
    /**
1125
     * @psalm-pure
1126
     *
1127
     * @param string|null $value
1128
     * @param string      $suffix
1129
     * @param string      $message
1130
     *
1131
     * @throws InvalidArgumentException
1132
     */
1133
    public static function nullOrEndsWith($value, $suffix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1134
1135
    /**
1136
     * @psalm-pure
1137
     *
1138
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1139
     * @param string           $suffix
1140
     * @param string           $message
1141
     *
1142
     * @throws InvalidArgumentException
1143
     */
1144
    public static function allEndsWith($value, $suffix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1145
1146
    /**
1147
     * @psalm-pure
1148
     *
1149
     * @param string|null $value
1150
     * @param string      $suffix
1151
     * @param string      $message
1152
     *
1153
     * @throws InvalidArgumentException
1154
     */
1155
    public static function nullOrNotEndsWith($value, $suffix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1156
1157
    /**
1158
     * @psalm-pure
1159
     *
1160
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1161
     * @param string           $suffix
1162
     * @param string           $message
1163
     *
1164
     * @throws InvalidArgumentException
1165
     */
1166
    public static function allNotEndsWith($value, $suffix, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1167
1168
    /**
1169
     * @psalm-pure
1170
     *
1171
     * @param string|null $value
1172
     * @param string      $pattern
1173
     * @param string      $message
1174
     *
1175
     * @throws InvalidArgumentException
1176
     */
1177
    public static function nullOrRegex($value, $pattern, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1178
1179
    /**
1180
     * @psalm-pure
1181
     *
1182
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1183
     * @param string           $pattern
1184
     * @param string           $message
1185
     *
1186
     * @throws InvalidArgumentException
1187
     */
1188
    public static function allRegex($value, $pattern, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1189
1190
    /**
1191
     * @psalm-pure
1192
     *
1193
     * @param string|null $value
1194
     * @param string      $pattern
1195
     * @param string      $message
1196
     *
1197
     * @throws InvalidArgumentException
1198
     */
1199
    public static function nullOrNotRegex($value, $pattern, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1200
1201
    /**
1202
     * @psalm-pure
1203
     *
1204
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1205
     * @param string           $pattern
1206
     * @param string           $message
1207
     *
1208
     * @throws InvalidArgumentException
1209
     */
1210
    public static function allNotRegex($value, $pattern, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1211
1212
    /**
1213
     * @psalm-pure
1214
     *
1215
     * @param mixed  $value
1216
     * @param string $message
1217
     *
1218
     * @throws InvalidArgumentException
1219
     */
1220
    public static function nullOrUnicodeLetters($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1221
1222
    /**
1223
     * @psalm-pure
1224
     *
1225
     * @param mixed  $value
1226
     * @param string $message
1227
     *
1228
     * @throws InvalidArgumentException
1229
     */
1230
    public static function allUnicodeLetters($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1231
1232
    /**
1233
     * @psalm-pure
1234
     *
1235
     * @param mixed  $value
1236
     * @param string $message
1237
     *
1238
     * @throws InvalidArgumentException
1239
     */
1240
    public static function nullOrAlpha($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1241
1242
    /**
1243
     * @psalm-pure
1244
     *
1245
     * @param mixed  $value
1246
     * @param string $message
1247
     *
1248
     * @throws InvalidArgumentException
1249
     */
1250
    public static function allAlpha($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1251
1252
    /**
1253
     * @psalm-pure
1254
     *
1255
     * @param string|null $value
1256
     * @param string      $message
1257
     *
1258
     * @throws InvalidArgumentException
1259
     */
1260
    public static function nullOrDigits($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1261
1262
    /**
1263
     * @psalm-pure
1264
     *
1265
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1266
     * @param string           $message
1267
     *
1268
     * @throws InvalidArgumentException
1269
     */
1270
    public static function allDigits($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1271
1272
    /**
1273
     * @psalm-pure
1274
     *
1275
     * @param string|null $value
1276
     * @param string      $message
1277
     *
1278
     * @throws InvalidArgumentException
1279
     */
1280
    public static function nullOrAlnum($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1281
1282
    /**
1283
     * @psalm-pure
1284
     *
1285
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1286
     * @param string           $message
1287
     *
1288
     * @throws InvalidArgumentException
1289
     */
1290
    public static function allAlnum($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1291
1292
    /**
1293
     * @psalm-pure
1294
     * @psalm-assert lowercase-string|null $value
1295
     *
1296
     * @param string|null $value
1297
     * @param string      $message
1298
     *
1299
     * @throws InvalidArgumentException
1300
     */
1301
    public static function nullOrLower($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1302
1303
    /**
1304
     * @psalm-pure
1305
     * @psalm-assert iterable<lowercase-string> $value
1306
     *
1307
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1308
     * @param string           $message
1309
     *
1310
     * @throws InvalidArgumentException
1311
     */
1312
    public static function allLower($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1313
1314
    /**
1315
     * @psalm-pure
1316
     *
1317
     * @param string|null $value
1318
     * @param string      $message
1319
     *
1320
     * @throws InvalidArgumentException
1321
     */
1322
    public static function nullOrUpper($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1323
1324
    /**
1325
     * @psalm-pure
1326
     *
1327
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1328
     * @param string           $message
1329
     *
1330
     * @throws InvalidArgumentException
1331
     */
1332
    public static function allUpper($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1333
1334
    /**
1335
     * @psalm-pure
1336
     *
1337
     * @param string|null $value
1338
     * @param int         $length
1339
     * @param string      $message
1340
     *
1341
     * @throws InvalidArgumentException
1342
     */
1343
    public static function nullOrLength($value, $length, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1344
1345
    /**
1346
     * @psalm-pure
1347
     *
1348
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1349
     * @param int              $length
1350
     * @param string           $message
1351
     *
1352
     * @throws InvalidArgumentException
1353
     */
1354
    public static function allLength($value, $length, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1355
1356
    /**
1357
     * @psalm-pure
1358
     *
1359
     * @param string|null $value
1360
     * @param int|float   $min
1361
     * @param string      $message
1362
     *
1363
     * @throws InvalidArgumentException
1364
     */
1365
    public static function nullOrMinLength($value, $min, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1366
1367
    /**
1368
     * @psalm-pure
1369
     *
1370
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1371
     * @param int|float        $min
1372
     * @param string           $message
1373
     *
1374
     * @throws InvalidArgumentException
1375
     */
1376
    public static function allMinLength($value, $min, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1377
1378
    /**
1379
     * @psalm-pure
1380
     *
1381
     * @param string|null $value
1382
     * @param int|float   $max
1383
     * @param string      $message
1384
     *
1385
     * @throws InvalidArgumentException
1386
     */
1387
    public static function nullOrMaxLength($value, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1388
1389
    /**
1390
     * @psalm-pure
1391
     *
1392
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1393
     * @param int|float        $max
1394
     * @param string           $message
1395
     *
1396
     * @throws InvalidArgumentException
1397
     */
1398
    public static function allMaxLength($value, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1399
1400
    /**
1401
     * @psalm-pure
1402
     *
1403
     * @param string|null $value
1404
     * @param int|float   $min
1405
     * @param int|float   $max
1406
     * @param string      $message
1407
     *
1408
     * @throws InvalidArgumentException
1409
     */
1410
    public static function nullOrLengthBetween($value, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1411
1412
    /**
1413
     * @psalm-pure
1414
     *
1415
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1416
     * @param int|float        $min
1417
     * @param int|float        $max
1418
     * @param string           $message
1419
     *
1420
     * @throws InvalidArgumentException
1421
     */
1422
    public static function allLengthBetween($value, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1423
1424
    /**
1425
     * @param mixed  $value
1426
     * @param string $message
1427
     *
1428
     * @throws InvalidArgumentException
1429
     */
1430
    public static function nullOrFileExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1431
1432
    /**
1433
     * @param mixed  $value
1434
     * @param string $message
1435
     *
1436
     * @throws InvalidArgumentException
1437
     */
1438
    public static function allFileExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1439
1440
    /**
1441
     * @param mixed  $value
1442
     * @param string $message
1443
     *
1444
     * @throws InvalidArgumentException
1445
     */
1446
    public static function nullOrFile($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1447
1448
    /**
1449
     * @param mixed  $value
1450
     * @param string $message
1451
     *
1452
     * @throws InvalidArgumentException
1453
     */
1454
    public static function allFile($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1455
1456
    /**
1457
     * @param mixed  $value
1458
     * @param string $message
1459
     *
1460
     * @throws InvalidArgumentException
1461
     */
1462
    public static function nullOrDirectory($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1463
1464
    /**
1465
     * @param mixed  $value
1466
     * @param string $message
1467
     *
1468
     * @throws InvalidArgumentException
1469
     */
1470
    public static function allDirectory($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1471
1472
    /**
1473
     * @param string|null $value
1474
     * @param string      $message
1475
     *
1476
     * @throws InvalidArgumentException
1477
     */
1478
    public static function nullOrReadable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1479
1480
    /**
1481
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1482
     * @param string           $message
1483
     *
1484
     * @throws InvalidArgumentException
1485
     */
1486
    public static function allReadable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1487
1488
    /**
1489
     * @param string|null $value
1490
     * @param string      $message
1491
     *
1492
     * @throws InvalidArgumentException
1493
     */
1494
    public static function nullOrWritable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1495
1496
    /**
1497
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1498
     * @param string           $message
1499
     *
1500
     * @throws InvalidArgumentException
1501
     */
1502
    public static function allWritable($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1503
1504
    /**
1505
     * @psalm-assert class-string|null $value
1506
     *
1507
     * @param mixed  $value
1508
     * @param string $message
1509
     *
1510
     * @throws InvalidArgumentException
1511
     */
1512
    public static function nullOrClassExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1513
1514
    /**
1515
     * @psalm-assert iterable<class-string> $value
1516
     *
1517
     * @param mixed  $value
1518
     * @param string $message
1519
     *
1520
     * @throws InvalidArgumentException
1521
     */
1522
    public static function allClassExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1523
1524
    /**
1525
     * @psalm-pure
1526
     * @psalm-template ExpectedType of object
1527
     * @psalm-param class-string<ExpectedType> $class
1528
     * @psalm-assert class-string<ExpectedType>|ExpectedType|null $value
1529
     *
1530
     * @param mixed         $value
1531
     * @param string|object $class
1532
     * @param string        $message
1533
     *
1534
     * @throws InvalidArgumentException
1535
     */
1536
    public static function nullOrSubclassOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1537
1538
    /**
1539
     * @psalm-pure
1540
     * @psalm-template ExpectedType of object
1541
     * @psalm-param class-string<ExpectedType> $class
1542
     * @psalm-assert iterable<class-string<ExpectedType>|ExpectedType> $value
1543
     *
1544
     * @param mixed         $value
1545
     * @param string|object $class
1546
     * @param string        $message
1547
     *
1548
     * @throws InvalidArgumentException
1549
     */
1550
    public static function allSubclassOf($value, $class, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1551
1552
    /**
1553
     * @psalm-assert class-string|null $value
1554
     *
1555
     * @param mixed  $value
1556
     * @param string $message
1557
     *
1558
     * @throws InvalidArgumentException
1559
     */
1560
    public static function nullOrInterfaceExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1561
1562
    /**
1563
     * @psalm-assert iterable<class-string> $value
1564
     *
1565
     * @param mixed  $value
1566
     * @param string $message
1567
     *
1568
     * @throws InvalidArgumentException
1569
     */
1570
    public static function allInterfaceExists($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1571
1572
    /**
1573
     * @psalm-pure
1574
     * @psalm-template ExpectedType of object
1575
     * @psalm-param class-string<ExpectedType> $interface
1576
     * @psalm-assert class-string<ExpectedType>|null $value
1577
     *
1578
     * @param mixed  $value
1579
     * @param mixed  $interface
1580
     * @param string $message
1581
     *
1582
     * @throws InvalidArgumentException
1583
     */
1584
    public static function nullOrImplementsInterface($value, $interface, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1585
1586
    /**
1587
     * @psalm-pure
1588
     * @psalm-template ExpectedType of object
1589
     * @psalm-param class-string<ExpectedType> $interface
1590
     * @psalm-assert iterable<class-string<ExpectedType>> $value
1591
     *
1592
     * @param mixed  $value
1593
     * @param mixed  $interface
1594
     * @param string $message
1595
     *
1596
     * @throws InvalidArgumentException
1597
     */
1598
    public static function allImplementsInterface($value, $interface, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1599
1600
    /**
1601
     * @psalm-pure
1602
     * @psalm-param class-string|object|null $classOrObject
1603
     *
1604
     * @param string|object|null $classOrObject
1605
     * @param mixed              $property
1606
     * @param string             $message
1607
     *
1608
     * @throws InvalidArgumentException
1609
     */
1610
    public static function nullOrPropertyExists($classOrObject, $property, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1611
1612
    /**
1613
     * @psalm-pure
1614
     * @psalm-param iterable<class-string|object> $classOrObject
1615
     *
1616
     * @param iterable<string|object> $classOrObject
0 ignored issues
show
The doc-type iterable<string|object> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1617
     * @param mixed                   $property
1618
     * @param string                  $message
1619
     *
1620
     * @throws InvalidArgumentException
1621
     */
1622
    public static function allPropertyExists($classOrObject, $property, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1623
1624
    /**
1625
     * @psalm-pure
1626
     * @psalm-param class-string|object|null $classOrObject
1627
     *
1628
     * @param string|object|null $classOrObject
1629
     * @param mixed              $property
1630
     * @param string             $message
1631
     *
1632
     * @throws InvalidArgumentException
1633
     */
1634
    public static function nullOrPropertyNotExists($classOrObject, $property, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1635
1636
    /**
1637
     * @psalm-pure
1638
     * @psalm-param iterable<class-string|object> $classOrObject
1639
     *
1640
     * @param iterable<string|object> $classOrObject
0 ignored issues
show
The doc-type iterable<string|object> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1641
     * @param mixed                   $property
1642
     * @param string                  $message
1643
     *
1644
     * @throws InvalidArgumentException
1645
     */
1646
    public static function allPropertyNotExists($classOrObject, $property, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1647
1648
    /**
1649
     * @psalm-pure
1650
     * @psalm-param class-string|object|null $classOrObject
1651
     *
1652
     * @param string|object|null $classOrObject
1653
     * @param mixed              $method
1654
     * @param string             $message
1655
     *
1656
     * @throws InvalidArgumentException
1657
     */
1658
    public static function nullOrMethodExists($classOrObject, $method, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1659
1660
    /**
1661
     * @psalm-pure
1662
     * @psalm-param iterable<class-string|object> $classOrObject
1663
     *
1664
     * @param iterable<string|object> $classOrObject
0 ignored issues
show
The doc-type iterable<string|object> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1665
     * @param mixed                   $method
1666
     * @param string                  $message
1667
     *
1668
     * @throws InvalidArgumentException
1669
     */
1670
    public static function allMethodExists($classOrObject, $method, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1671
1672
    /**
1673
     * @psalm-pure
1674
     * @psalm-param class-string|object|null $classOrObject
1675
     *
1676
     * @param string|object|null $classOrObject
1677
     * @param mixed              $method
1678
     * @param string             $message
1679
     *
1680
     * @throws InvalidArgumentException
1681
     */
1682
    public static function nullOrMethodNotExists($classOrObject, $method, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1683
1684
    /**
1685
     * @psalm-pure
1686
     * @psalm-param iterable<class-string|object> $classOrObject
1687
     *
1688
     * @param iterable<string|object> $classOrObject
0 ignored issues
show
The doc-type iterable<string|object> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1689
     * @param mixed                   $method
1690
     * @param string                  $message
1691
     *
1692
     * @throws InvalidArgumentException
1693
     */
1694
    public static function allMethodNotExists($classOrObject, $method, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1695
1696
    /**
1697
     * @psalm-pure
1698
     *
1699
     * @param array|null $array
1700
     * @param string|int $key
1701
     * @param string     $message
1702
     *
1703
     * @throws InvalidArgumentException
1704
     */
1705
    public static function nullOrKeyExists($array, $key, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1706
1707
    /**
1708
     * @psalm-pure
1709
     *
1710
     * @param iterable<array> $array
0 ignored issues
show
The doc-type iterable<array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1711
     * @param string|int      $key
1712
     * @param string          $message
1713
     *
1714
     * @throws InvalidArgumentException
1715
     */
1716
    public static function allKeyExists($array, $key, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1717
1718
    /**
1719
     * @psalm-pure
1720
     *
1721
     * @param array|null $array
1722
     * @param string|int $key
1723
     * @param string     $message
1724
     *
1725
     * @throws InvalidArgumentException
1726
     */
1727
    public static function nullOrKeyNotExists($array, $key, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1728
1729
    /**
1730
     * @psalm-pure
1731
     *
1732
     * @param iterable<array> $array
0 ignored issues
show
The doc-type iterable<array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1733
     * @param string|int      $key
1734
     * @param string          $message
1735
     *
1736
     * @throws InvalidArgumentException
1737
     */
1738
    public static function allKeyNotExists($array, $key, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1739
1740
    /**
1741
     * @psalm-pure
1742
     * @psalm-assert array-key|null $value
1743
     *
1744
     * @param mixed  $value
1745
     * @param string $message
1746
     *
1747
     * @throws InvalidArgumentException
1748
     */
1749
    public static function nullOrValidArrayKey($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1750
1751
    /**
1752
     * @psalm-pure
1753
     * @psalm-assert iterable<array-key> $value
1754
     *
1755
     * @param mixed  $value
1756
     * @param string $message
1757
     *
1758
     * @throws InvalidArgumentException
1759
     */
1760
    public static function allValidArrayKey($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1761
1762
    /**
1763
     * @param Countable|array|null $array
1764
     * @param int                  $number
1765
     * @param string               $message
1766
     *
1767
     * @throws InvalidArgumentException
1768
     */
1769
    public static function nullOrCount($array, $number, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1770
1771
    /**
1772
     * @param iterable<Countable|array> $array
0 ignored issues
show
The doc-type iterable<Countable|array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1773
     * @param int                       $number
1774
     * @param string                    $message
1775
     *
1776
     * @throws InvalidArgumentException
1777
     */
1778
    public static function allCount($array, $number, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1779
1780
    /**
1781
     * @param Countable|array|null $array
1782
     * @param int|float            $min
1783
     * @param string               $message
1784
     *
1785
     * @throws InvalidArgumentException
1786
     */
1787
    public static function nullOrMinCount($array, $min, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1788
1789
    /**
1790
     * @param iterable<Countable|array> $array
0 ignored issues
show
The doc-type iterable<Countable|array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1791
     * @param int|float                 $min
1792
     * @param string                    $message
1793
     *
1794
     * @throws InvalidArgumentException
1795
     */
1796
    public static function allMinCount($array, $min, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1797
1798
    /**
1799
     * @param Countable|array|null $array
1800
     * @param int|float            $max
1801
     * @param string               $message
1802
     *
1803
     * @throws InvalidArgumentException
1804
     */
1805
    public static function nullOrMaxCount($array, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1806
1807
    /**
1808
     * @param iterable<Countable|array> $array
0 ignored issues
show
The doc-type iterable<Countable|array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1809
     * @param int|float                 $max
1810
     * @param string                    $message
1811
     *
1812
     * @throws InvalidArgumentException
1813
     */
1814
    public static function allMaxCount($array, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1815
1816
    /**
1817
     * @param Countable|array|null $array
1818
     * @param int|float            $min
1819
     * @param int|float            $max
1820
     * @param string               $message
1821
     *
1822
     * @throws InvalidArgumentException
1823
     */
1824
    public static function nullOrCountBetween($array, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1825
1826
    /**
1827
     * @param iterable<Countable|array> $array
0 ignored issues
show
The doc-type iterable<Countable|array> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1828
     * @param int|float                 $min
1829
     * @param int|float                 $max
1830
     * @param string                    $message
1831
     *
1832
     * @throws InvalidArgumentException
1833
     */
1834
    public static function allCountBetween($array, $min, $max, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1835
1836
    /**
1837
     * @psalm-pure
1838
     * @psalm-assert list|null $array
1839
     *
1840
     * @param mixed  $array
1841
     * @param string $message
1842
     *
1843
     * @throws InvalidArgumentException
1844
     */
1845
    public static function nullOrIsList($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1846
1847
    /**
1848
     * @psalm-pure
1849
     * @psalm-assert iterable<list> $array
1850
     *
1851
     * @param mixed  $array
1852
     * @param string $message
1853
     *
1854
     * @throws InvalidArgumentException
1855
     */
1856
    public static function allIsList($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1857
1858
    /**
1859
     * @psalm-pure
1860
     * @psalm-assert non-empty-list|null $array
1861
     *
1862
     * @param mixed  $array
1863
     * @param string $message
1864
     *
1865
     * @throws InvalidArgumentException
1866
     */
1867
    public static function nullOrIsNonEmptyList($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1868
1869
    /**
1870
     * @psalm-pure
1871
     * @psalm-assert iterable<non-empty-list> $array
1872
     *
1873
     * @param mixed  $array
1874
     * @param string $message
1875
     *
1876
     * @throws InvalidArgumentException
1877
     */
1878
    public static function allIsNonEmptyList($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1879
1880
    /**
1881
     * @psalm-pure
1882
     * @psalm-template T
1883
     * @psalm-param mixed|array<T>|null $array
1884
     * @psalm-assert array<string, T>|null $array
1885
     *
1886
     * @param mixed  $array
1887
     * @param string $message
1888
     *
1889
     * @throws InvalidArgumentException
1890
     */
1891
    public static function nullOrIsMap($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1892
1893
    /**
1894
     * @psalm-pure
1895
     * @psalm-template T
1896
     * @psalm-param iterable<mixed|array<T>> $array
1897
     * @psalm-assert iterable<array<string, T>> $array
1898
     *
1899
     * @param mixed  $array
1900
     * @param string $message
1901
     *
1902
     * @throws InvalidArgumentException
1903
     */
1904
    public static function allIsMap($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1905
1906
    /**
1907
     * @psalm-pure
1908
     * @psalm-template T
1909
     * @psalm-param mixed|array<T>|null $array
1910
     *
1911
     * @param mixed  $array
1912
     * @param string $message
1913
     *
1914
     * @throws InvalidArgumentException
1915
     */
1916
    public static function nullOrIsNonEmptyMap($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1917
1918
    /**
1919
     * @psalm-pure
1920
     * @psalm-template T
1921
     * @psalm-param iterable<mixed|array<T>> $array
1922
     *
1923
     * @param mixed  $array
1924
     * @param string $message
1925
     *
1926
     * @throws InvalidArgumentException
1927
     */
1928
    public static function allIsNonEmptyMap($array, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1929
1930
    /**
1931
     * @psalm-pure
1932
     *
1933
     * @param string|null $value
1934
     * @param string      $message
1935
     *
1936
     * @throws InvalidArgumentException
1937
     */
1938
    public static function nullOrUuid($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1939
1940
    /**
1941
     * @psalm-pure
1942
     *
1943
     * @param iterable<string> $value
0 ignored issues
show
The doc-type iterable<string> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1944
     * @param string           $message
1945
     *
1946
     * @throws InvalidArgumentException
1947
     */
1948
    public static function allUuid($value, $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1949
1950
    /**
1951
     * @psalm-param class-string<Throwable> $class
1952
     *
1953
     * @param Closure|null $expression
1954
     * @param string       $class
1955
     * @param string       $message
1956
     *
1957
     * @throws InvalidArgumentException
1958
     */
1959
    public static function nullOrThrows($expression, $class = 'Exception', $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1960
1961
    /**
1962
     * @psalm-param class-string<Throwable> $class
1963
     *
1964
     * @param iterable<Closure> $expression
0 ignored issues
show
The doc-type iterable<Closure> could not be parsed: Expected "|" or "end of type", but got "<" at position 8. (view supported doc-types)

This check marks PHPDoc comments that could not be parsed by our parser. To see which comment annotations we can parse, please refer to our documentation on supported doc-types.

Loading history...
1965
     * @param string            $class
1966
     * @param string            $message
1967
     *
1968
     * @throws InvalidArgumentException
1969
     */
1970
    public static function allThrows($expression, $class = 'Exception', $message = '');
0 ignored issues
show
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
1971
}
1972