Re: [RFC] Mixed Typehint

On 12/19/2017 6:43 PM, Andreas Hennings wrote: > The argument, which I support, is that "mixed" would allow to > distinguish against cases of "developer forgot to add a type hint" or > "no type hint due to legacy / BC reasons". > Also, with a "mixed" type hint, you know it is not "void" (this is > still the same argument). > The developer forgot the type constraint if there is no type constraint in: 1. the code 2. the DocBlock This is a simple rule that you can already adopt without any changes to the language. The thing is that mixed is not required at all at the moment PHP supports more sophisticated type constructs. As I said earlier, pursue them, not this. PS: It's interesting how people fail to see the power of union and intersection. This is currently happening on the Kotlin side too. A simple example for a union type was already given: string|int. Although in this case I would argue that anything that is convertible to a hash (e.g. Hashable as found in php-ds) and ensures an equivalence relation (not partial like float) should be usable as a key in an associative array. The introduction of dedicated types for this is definitely required in the language. That being said, union types are usually of interest if you are interacting with some library code that you cannot change (e.g. add interfaces to an existing type). Of course, one could argue that the introduction of dedicated interfaces in your own codebase plus adapters is the way to go but this requires much more effort than the in-place union declaration. Discriminating unions would be much nicer but that is something a proper enum impl should cover. Intersection is a whole other beast that is actually more powerful than the simple unions we know from PhpDoc. Consider the following example: interface Writer interface Reader interface Seekable interface AutoCloseable interface Closeable We could now continue and provide ReadableWriter, SeekableWriter, SeekableReadableWriter, ... but this already gets out of hand. An intersection on the other hand allows you to define exactly the features you require: fn f(Closeable & Seekable & Writer writer) This can of course be provided with a generics impl which would probably make the parsing impl simpler: fn f<T: Closeable + Seekable + Writer>(T writer) -- Richard "Fleshgrinder" Fussenegger