You also don't need to pay it to own a vehicle. You are allowed to own a vehicle without paying this tax as long as you promise not to drive it on the road (SORN). So by that logic it's not a vehicle tax either.

Also, bicycles are vehicles. So surely they should pay Vehicle Tax as well?

A more accurate name would be the "Using a Motorized Vehicle on the Public Road Tax". Let's abbreviate it by dropping all but the last two words. :)

"Road tax" is a _tax_ you have to pay in order to use the _road_. It's the most natural name for it, which is why people call it that.

Despite the words they use, it's not a vehicle tax: you can own a vehicle without paying it as long as you declare that you will not use the vehicle _on_the_road_ (a.k.a., make a Statutory Off Road Notification). It's a tax for using the roads. A road tax.

That the government don't ring-fence it to use on road maintenance is irrelevant.

> That the government don't ring-fence it to use on road maintenance is irrelevant.

It's not irrelevant to the quoted section, which is the only thing the previous poster was replying to.

> Issues of standards are not really depending on funding

This is clearly not true, otherwise we could just cut all the funding and maintain the standards as they are.

We're discussing standards or professional conduct.

Funding gets you more police officers but their conduct depends on management and leadership, not on extra funding (at least as long as funding allows for decent salaries).

In this case, and again others that have hit the news, funding is quite irrelevant, the issue is organisational.

Phone charger regulations were based on the need to reduce e-waste caused by every phone having a different charger.

I think the same principle could be applied here. Heated seats that can't be used are causing increased emissions as the car needs to move them around without actually providing any benefit to the owner, and so should be regulated.

Once you open that can of worms you’d have to regulate SUVs out of existence entirely.

Sounds good to me.

(Half kidding, half serious. If they are really that harmful, maybe a ban wouldn't be the craziest idea)

What's the one for third-party apps? How different is the wording?

Automatic triggering seems like a recipe for disaster. My car has a version of this that shows the current speed limit on the display. It is frequently wrong. A road near me shows up as 20mph despite being 30 or 40 in different parts. Other times it sees signs for access roads or side roads and misinterpret them as for the current road (sometimes saying 20mph in a 60mph zone).

It's a nice idea, but the tech really isn't there yet. I guess a few high profile incidents and they'll be forced to fix it.

Yeah, you couldn't possibly roll out automatic triggering without also creating laws to uniformize how speed limits are set and data shared about them across the US (I don't refer to taking away agency from the many local jurisdictions that can affect speed limits for the bajillions of stretches of roadway in the country-- just standardizing requirements so that when some tiny little town adjusts the speed limit frfom 25 to 20 on a 2 block stretch of main street, except after 6PM monday to friday, there is a standard way for them to notify a national DOT database electronically and they are required to do that prior to enforcement)

That alone probably makes it a nonstarter in the USA, right?

Tabs are implementation defined control characters. I don't want to say you can't use them, but if you do, then I get to use BEL. ;)

Why is that weird? Procedural macros are compiler plugins. They get compiled for the platform you're building on, not the one you're building for, and so they need to be a separate compilation unit. In Rust, the crate is the compilation unit.

Because you can't just throw together a simple procedural macro to use in a specific project, as you can in other languages.

It's not necessarily a "re-"throw. It could just be a throw of a newly detected error, like:

    try {
        if bad_thing {
            do yeet Error::new(...);
        }
        carry_on()
    }

Just plain "throw" would probably be fine, but I understand not wanting to bikeshed it at this stage.

Weirdly, "yeet" really does convey the sense of "just give up and chuck this thing back instead" that makes it a reasonable nice converse of "try", i.e. "try { yeet }".

> Alas, counting in macro by example is possible, but not trivial.

It's not stabilized yet, but RFC3086[1] introduces macro metavariable expressions, which make counting trivial!

The example macro becomes:

    macro_rules! define_error {
      ($($err:ident,)*) => {
        #[derive(Debug, Clone, Copy, PartialEq, Eq)]
        pub enum Error {
          $($err,)*
        }
    
        impl Error {
          pub fn from_code(code: u32) -> Option<Error> {
            match code {
              $( ${index()} => Some(Error::$err), )*
              _ => None,
            }
          }
        }
      };
    }

You can see this in practice on the playground[2].

[1]: https://github.com/rust-lang/rfcs/blob/master/text/3086-macr... [2]: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Thanks for the link, that seems very useful. I recently had to work around this by transforming a list (a, b, c, d) into something like 1+1+1+1+0 to get a count. What this RFC proposes looks so much less painful.

There's much cooler approach: https://veykril.github.io/tlborm/decl-macros/building-blocks....

  macro_rules! count {
      () => (0);
      ($odd:tt ($a:tt $b:tt)*) => ((count!($($a)*) << 1) | 1);
      (($a:tt $b:tt)*) => (count!($($a)*) << 1);
  }

It uses bit twiddling to avoid generating very big AST and eventually crashing the compiler. Though I have to admit using `${count()}` is better.