masklinn

That is indeed a person who did not, can not, or will not read instructions.

And what, pray tell, is the rule about?

I didn't miss the joke, the joke missed the point.

> I personally answered "not breaking the rule" to emergency vehicles

> You might know of some rule in your jurisdiction which overrides local rules, and allows certain classes of vehicles. Please disregard these rules; the park isn't necessarily in your jurisdiction.

The game is entirely about what constitutes "a vehicle" and what constitutes "in the park", it explicitly instructs against "what do I personally think should be allowed in the park".

> police are allowed to violate rules in certain cases.

Probably more relevant, such services usually get legal carve outs for purpose.

But the game specifically instructs the player to ignore any such consideration.

The game specifically instructs to disregard justification, overrides, carve-outs, etc...

It only asks two questions, strictly: is it a vehicle, and is it in the park.

So yes, francesca's car being a vehicle and in the park is a violation.

> If it is both a vehicle and in the park, is justified?

> Is a justified violation of the rules still to be considered a violation? reply

Given the introductory text, neither is relevant:

> You might know of some rule in your jurisdiction which overrides local rules, and allows certain classes of vehicles. Please disregard these rules; the park isn't necessarily in your jurisdiction. Or perhaps your religion allows certain rules to be overridden. Again, please answer the question of whether the rule is violated (not whether the violation should be allowed).

They absolutely do in practical non-generic code. A case I personally encounter regularly is json APIs which distinguish between a key being missing and one being set to null in a structure.

Gmail? I don’t recall that being an acqui.

Around here late morning to mid afternoon (11 am to 4 pm) is now off-peak, alongside the old 10pm to 6 am.

I thin the part that you missed is that a MutexGuard is an owned value. That’s the gain of having a mutex guard projection, the projection is an owned type which keeps the lock, well, locked. Having a field projection return a reference is no use because… that already works fine today, it’s deref. But that does not work if you need an owned reference. Same for field projecting everything else e.g. an arc.

> A field in the RenderState should not have a guard unless it has its own mutex!

I don’t agree with that. The original mutex gives access to the field via its guard, nothing wrong with keeping the guard and the field and getting rid of the stricture around it (for the purpose of access). It’s not like mutex guards have a static identity relationship to their mutex.

I don’t know, maybe because rust is of interest to the wider Linux community and has been pretty much since its inception (https://lwn.net/Articles/547145/)?

And with the inclusion of rust in the kernel, and thus the kernel’s need to express its own abstractions and requirements (as well as the impossibility to use alloc and thus box) the limitations (ergonomic and otherwise) of “userland” smart pointers are more salient and relevant than ever.

> Rather, introducing even more potential implicitness on every `.` seems like it would make the language harder to learn.

The problem is that built-in pointers (references and box) are already special cased in the compiler to Just Work (tm), so this creates confusion when switching between those builtins and third-party pointers, or even stdlib pointers which aren’t special cased by the compiler.

So this is less about “potential implicitness on every .” and more about making places more first-class, and non-builtin smart pointers (both first and third class) being better able to express their semantics to the compiler, to lift every pointer to the ergonomic capabilities of builtins.

There are many ways to preserve apples even before refrigeration (sauces, jams, jellies, juices, canned slices, dehydrated, ...). Also the right varieties of apples ("winter apples") store fine for months, some in excess of a year, in a cool and damp cellar.

And cooking and dessert apples don't make for great cider. While sugar is important (and cider apples can have more than dessert or cooking apples), tanins, acidity, and phenols are also very useful to cidermaking even though they make the apples themselves rather unpalatable.

Historically non-edible apples (grown from seed, as well as dedicated cider apples) are widely available and only useful for cider, so it would be a waste of an edible apple to make cider out of it.

> Ironically Oracle [...] is now being the good guy.

Reminder: oracle is also an acronym, and you might want to take a gander at what its subject is up to.

There is no future in which oracle is the good guy no matter the axis. Least of all the subject of AI.

> You either accept

That is a false dichotomy. Some enumerations have reasons to likely change in the future, others (most) either have no such thing or their changing would be so impactful to the system it needs to be signaled loudly.

That’s really no different than any other type information.

> It's always a tradeoff and you can also always fork or propose your own improved version of the concept

You are the person asserting that the concept as defined is incorrect.

Not really.

Defaulting to exhaustive pattern matches is correct, it’s by far the most frequent case (which is why essentially every modern language does that); being able to prevent exhaustive matching is useful for libraries; and using a private subclass is a completely obvious way to implement that in Java.

See private extensible variants for the same capability in OCaml. Or the non_exhaustive attribute in Rust. Or the nonexhaustive attribute in Swift (or alternatively opting into library-evolution which reverses the defaults).

The european rabbit (and the domesticated rabbit, which descends from it) is native to the Iberian peninsula. There are ~20 extant species called rabbits all over the world (most though not all leporids outside of Lepus, the true hares).

Rabbit is a pretty important part of traditional Maltese cuisine, rabbit stew is often considered a national dish, fried rabbit is also fairly common.

First time I heard of rabbit being considered to taste like chicken, they taste nothing alike.

> But the format could be used with a lenient parser if anyone wanted that

Congratulation on reinventing HTML.

> HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it.

Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html

> But the anti-XML sentiment was explicit and spiteful.

No, xhtml was just a bad idea creating tons of problems and solving none.

> the surface could not be tempered glass […] a sheet of which costs maybe $30 per square foot, but a special, newly created material called Dekton that cost five times as much

Seems like he’s giving a ballpark of 150 here.

> Leap seconds have been in from the start so all software should be able to handle them. But obviously we have no confidence in that actually being true.

We in fact have high confidence that it’s not true. Google started leap smearing back in 2008 because so much broke on leap seconds.

Honestly I’d think a negative leap second would have way higher chances of just working than positive: a positive leap second causes a minute to have a 61st second, and a unix timestamp to repeat. That is a highly rare condition and plays complete havoc on software which does not specifically support these.

A negative leap just means jumping a second, this is already relatively routine due to scheduling and suspends, your program can do one thing and then 20 minutes occur before the next, because right then the user closed their laptop lid.

> But there’s still no way to get consistent results cross-platform without a web view, right?

… good? I want my applications to be consistent with the platform they run on, not with their own stupidity on other platforms.

TBF that’s been EGS’s model since day 1 of trying to kill steam.

That they’ve failed miserably has been one of the few good news since.

> Note that Rust is not a theorem prover

Not that that would make any difference, theorem provers can also have bugs. Famously this summer someone “disproved” the collatz conjecture by exploiting a soundness bug in Lean.

Unsoundness and UB are very different things, UB tells users of the language "don't do that it's wrong", unsoundness tells users of the language "be careful we need to fix that", it's a bug.

And this, kids, is how you get called Billy Madison.

May god have mercy on your soul, cowlevel1.

Afaik loop {} has never been UB, however because llvm started as a c++ compiled where it is, this has been causing miscompilations in rust and C for… nearly two decades (llvm issue 965).