'Fail's behavior within a selector

gistfile1.pp

# Currently the pattern used when implementing a params class is something like this.
# It works but is very verbose for what it does.

class puppet::params{
  # In this case we are only specializing based on one parameter
  case $::osfamily {
    'Debian': {
      $conf_file_path = '/etc/puppet/puppet.conf'
    }
    default: {
      fail("${::osfamily} is not supported by this module")
    }
  }

  #in this case we are specializing based on multiple parameters
  case $::osfamily {
    'Debian': {
      case $::operatingsystem {
        'Debian': {
          $vardir = '/var/lib/puppet'
        }
        default: {
          fail("operatingsystem ${::operatingsystem} is not supported by this module")
        }
      }
    }
    default: {
      fail("osfamily ${::osfamily} is not supported by this module")
    }
  }
}

# This pattern is probably unfamiliar but is very concise and clean looking.

class puppet::params(
  # In this case we are only specializing based on one parameter
  $conf_file_path = $::osfamily ? {
    'Debian' => '/etc/puppet/puppet.conf',
    default  => fail("${::osfamily} is not supported by this module"),
  },
  #in this case we are specializing based on multiple parameters
  $vardir = $::osfamily ? {
    'Debian' => $operatingsystem ? {
        'Debian' => '/var/lib/puppet',
        default  => fail("operatingsystem ${::operatingsystem} is not supported by this module"),
    },
    default => fail("osfamily ${::osfamily} is not supported by this module"),
  },
){}

# With the new parser this is almost valid. The only problem with it is the fail function doesn't return
# an rvalue so the parser doesn't consider it valid.
# I'd like to see this changed. Functions like fail shouldn't be checked to see if they return a value
# since they exist to interrupt the flow of execution and allowing them to be used in a case like this
# would allow for more concise clean looking code.