> sketch out a more complete picture for the type system. We can implement it in pieces and parts, but we should have a goal in mind for where we want to land.
I think the type system in psalm is pretty cool. It does have fixed literal values, but also deeply structured array types. But: - I don't think we'll arrive there in one leap - I am not sure we _want_ to arrive there, ever. Perhaps it is just too much for native support, especially if we want repeated runtime checks. - Runtime checks on array types seem like a nightmare. - I am pretty confident that adding `true` won't close any doors fur future type systems, if we already have `false`. Alternatively we could look at compile-time type systems like in C++ (or Java?), where we don't have to waste time on runtime checks. The default implicit variable type could be "variant", but variables with a declared type would behave as in C++, with a faster and slimmer storage model. Of course any union type that allows values other than object or null would have to use the storage model of "variant". Sounds like a lot of work, but if we want to dream big, it is something to consider. (There might be better examples than C++, I only mention it because I spent some time with it long ago. Perhaps even Java?) -- Andreas On Mon, 11 Apr 2022 at 18:18, Sara Golemon <poll...@php.net> wrote: > > On Mon, Apr 11, 2022 at 8:59 AM Tim Düsterhus <t...@bastelstu.be> wrote: > > For `true` the story is different, as this type is an entirely new type > > available to userland and by the same argument one could have literal > > strings or literal integers as distinct types as well. I wouldn't object > > to that per se (and there's precedent in TypeScript), but there could be > > a clearer plan for the type system as a whole, instead of adding types > > piecemeal. > > > > ^This. The bit about making a plan, I mean. A slow erosion of what it > means to be a type might be the easier pill to swallow, but it results in > more chaos overall in the type system. I'd like to see someone (literally > anyone) take the time to sketch out a more complete picture for the type > system. We can implement it in pieces and parts, but we should have a goal > in mind for where we want to land. > > Using this RFC as an example, it naturally leads into the question of value > types (which is what `true` really is, a bool with a value of true), so why > can't we say this method must return the number 42 or a string containing > 'pamplemousse' ? A roadmap would help us understand what those kinds of > value types (in an unbounded type like string or a large bounded type like > int) compared to the tight bounded type of bool. > > And yes. Generics. We can't talk about the type system without the > subject of generics being extremely relevant. Ignoring them because it's > complicated is just kicking the can down the road. > > All that having been said, sure. I don't mind adding true for completeness, > because it's fairly obvious and the scope of bool is fairly small, but I > would really encourage anyone to step up and plan out a wider reaching goal > for the type system. > > -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
