I had imagined the way things like $R = 0 but true would work is that the scalar would grow another couple of slots in it, which would be the conversion operators. Everything defaults to how it has worked in the past, but could be overridden. So the boolean value starts as "default converter" until it gets accessed, then the language figures out what the boolean value is and caches it until an assignment happens and clears the boolean (and other autoconverted) value. That allows booleans to get set to values other than perl 5 truth of the scalar contents. It also meshes well with alternate v-tables, although profusion of what can be done by multiplying the number of vtables and what is better done with a per-access check is a good case for some modeling and some algebra and some benchmarking on various platforms: Maybe we could have a slider in the performance tuning widget. But if the additional slots in the scalar are cleared at assignment, that is a very different sort of assignment to an item than a "property" such as "will only hold integers" or "will only hold dogs or dog subtypes" which does not vary and can be used by the compiler. I propose: use "but" to override the default intrascalarvalue conversions, such as $line = readline but true; or even better, $line = readline; $line = $line but boolean(is_section_end_markerp($line)); Although this second use begs the question, "Why bother with combining types if you're going to override them?" Maybe overriding is not such a good idea anyway? Are there really that many situations where having Truth autogenerated from number/text-string isn't confusing and bug-prone already? reserve "is" for compiler optimization hints: my $line is text; I have not read the earlier discussion in the thread I am adding this posting to, or the essays referred to by them. The above is/but distinction is something that I believe needs to be made, by any names, because without it there will be confusionsThread Previous | Thread Next