features_block to feature.if/else

[titzer]

After seeing @tlively's presentation today, I offhandedly suggested using else to allow a feature-block to have an alternative. I think it would be somewhat elegant to generalize features_block ... end to feature.if [block_type] ... else ... end. Thus it would look a lot like a regular if, but the true block would be a binary blob that would not be decoded if the feature set is not supported.

We would have to decide what to do with block_type in the else block. One option would be to have a completely alternate type for else or to have the same block_type, but with alternative types substituted in.

[titzer]

Actually, now that I think about it, it is almost certainly needed to have an alternative type for the else, because it might not be possible to decode the block type at all if the feature isn't supported.

[tlively]

What would the benefit of this approach be over having feature_block decode as an unreachable? I would expect the unbundled feature_block to offer slightly more control flow flexibility to producers but otherwise be mostly identical.

[titzer]

It would be symmetric with the conditional types, which are proposed to allow an alternative type if not supported.

[tlively]

That's fair. (If we had an explicit bottom type I would have reached for that instead for feature_type, but we don't.)