Individuals in the US, even if a vast majority, being nice and happy that you visit doesn't stop the possibility of legally being held at a port of entry for any reason, even with a valid visa. This isn't new, although the frequency of this happening and reported has gone up.
I cannot understand this sentiment. If you commit a crime in a country and don't pay the fine, why would you be surprised if they made you pay the fine next time you crossed the border? Even if it were a parking ticket I wouldn't find Canada's actions here objectionable, and DUI is a lot more serious than that. Unless I've misunderstood the scenario you're describing.
She didn’t commit the DUI in Canada, she did in the US. We were in the country for three days (Victoria) and didn't even have a car, so she couldn’t have recommitted the offense even if she wanted to, which she obviously wouldn’t want to.
She committed a serious crime and didn't pay the penalty which normally in the US comes with additional criminal penalties for non-payment. They would have been perfectly justified to extradite her and take her to jail.
Also how can you say that she couldn't offend again? She could easily rent or drive another.
I think you don't understand what has happened here. OP's wife has a DUI in the USA. Canada does not normally allow people with a DUI into Canada. In exchange for $250, they allowed her in. This is both a surprise and a nuisance for OP.
It sounded to me like she paid her US fine and thus ceased to be a scofflaw. After further reading it looks like convicted criminals can apply for a temporary residence permit for CAN $239.75.
This may not be needed if 5+ years have passed without further misdeeds and may apply to be deemed rehabilitated.
This covers individual evaluation of your case and may be denied. It probably also serves to keep the riff raff put especially Americans who otherwise may take a day trip to share their further drunken driving adventures with their least lucky Canadian friends.
It is hard to contextualize this as a bribe with poster as a victim when the very reasonable alternative is simple denial.
You have no right to visit Canada and they can charge you as much as they please and its your responsability to do your own homework as far as travel requirements.
I don't understand the comparison. Was she at risk of being locked up for days or weeks? People aren't worried about being denied entry. People are worried about having their rights violated.
> Worst case is that the compiler does a bad job at explaining the error and you don't find it immediately.
By the way, the project considers this a bug and accepts reports for that. In many occasions they are easy to fix. In others large refactors are needed. But being aware of the case is the necessary first step to making them better.
The only issue with it is that Rust's aversion to half-baked code means that you can't have "partially working code" during the refactor: you either finish it or bail on it, without the possibility to have inconsistent codebase state. This is particularly annoying for exploratory code.
On the other hand, that strictness is precisely what leads people to end up with generally reasonable code.
I find a healthy dose of todo!() is excellent for this.
match foo {
(3...=5, x, BLABLABLA) => easy(x),
_ => todo!("I should actually implement this for non-trivial cases"),
}
The nice thing about todo!() is that it type checks, obviously it always diverges so the type match is trivial, but it means this compiles and, so long as we don't cause the non-trivial case to happen, it even works at runtime.
The thing is I want an equivalent to `todo!()` for the type-system. A mode of operation where if you have some compile errors, you can still run tests. Like for example, if you have
fn foo() -> impl Display {
NotDisplay::new()
}
and a test references `foo`, then it gets replaced for the purposes of the test with
So maybe a proc macro which lets you #[dummy(Clone,Eq,PartialEq)] instead of #[derive(Clone,Eq,PartialEq)] ?
Although you said "mode of operation" and I can't get behind that idea, I think the choice to just wrap overflow by default for the integer types in release builds was probably a mistake. It's good that I can turn it off, but it shouldn't have been the default.
What's the advantage of that over putting `return todo!();` at the top of `foo()`? You do have to go through and mark the places where you have further work to do, but you don't have to finish the refactor.
I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should. Think borrow checking, for example. If it could be changed automatically to Arc<Mutex<T>> from &T, when running the test you could say not only the borrow checker error, but also point at the specific runtime case that the borrow checker protected you from if any test exercises it.
Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
And these strategies are things that people need to be taught about, individually. I'm not saying that the current state is terrible, just that there might be things we can do to make them better.
> I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should.
I do think that'd be useful in a variety of cases, especially for testsuites. I don't think I'd want to go as far as trying to guess how to substitute `Arc`/`Mutex`/`RwLock` for a failed borrow, but there are a few different strategies that do seem reasonably safe.
In addition to the automatic todo!() approach, there's the approach of compile-time tainting of branches of the item tree that failed to compile. If something doesn't compile, turn it into an item that when referenced makes the item referencing it also fail to compile. That would then allow any items that do compile to get tested in the testsuite.
> Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
Not in the fully general case, but ! does implement Display, so it would work in the case you posted.
It's a tradeoff, reminds me of Go not compiling if you have an unused variable; the strictness is a feature and basically locks out sloppy / half baked code.
I personally see Rust as an ideal "second system" language, that is, you solve a business case in a more forgiving language first, then switch (parts) to Rust if the case is proven and you need the added performance / reliability.
Fsharp's type inference is great in that regard. Function types are inferred too, in contrast with rust.
I find fsharp fit for exploratory code, and its type inference is probably the enabler.
The security concerns are those of "Trojan source", where the displayed text doesn't correspond to the bytes on the wire.[1]
I don't think a wire protocol should necessarily restrict them, for the sake of compatibility with existing text corpus out there, but a fair observation.
The enforcement is an app-level issue, depending on the semantics of the field. I agree it doesn't belong in the low-level transport protocol.
The rules for "username", "display name", "biography", "email address", "email body" and "contents of uploaded file with name foo.txt" are not all going to be the same.
Or let them be ignored within the root crate when building a binary, since the main concern with orphans is that libraries deep in your dependency tree become accidentally incompatible, which isn't a problem if orphans arise in the root of a binary crate, since by definition you control its source.
It's a matter of what use cases are catered to by default, and what use cases are possible. For example, having debug symbols on by default makes it easier to start using the language and debug your applications, at the cost of more disk space and having to configure your project if your needs are different. I think the discussion would have more merit if the defaults weren't configurable. But of course, the choice of defaults is one that will be contentious no matter what. It should still be done following the Hippocratic Oath of "first, do no harm". And some of us need to accept that our usecases are more niche than others, including mine.
Valhalla is indeed the one effort that could close the biggest gap with native languages. Java Vs C or Rust for networked applications have comparable CPU utilisation with comparable throughput, but memory consumption can be >100x. Project Valhalla is the only thing that could potentially change that. The problem I do see is that even after the language and JVM have value types, the vast extense of libraries that people use are unlikely to change to leverage them. But for projects that control most of their own dependencies, it will be a clear win.
reply