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
