Primarily because it encourages people to keep doing this performative stuff, think they're actually helping people, and take resources away from more meaningful work. By resisting these efforts, I'm preventing what would likely be runaway acceleration.
In theory, the actual individuals are still bound by state law, but the supremacy clause allows federal laws made in pursuance of the US Constitution to preempt those state laws. Of course, these laws still need to be "necessary and proper" for carrying out an express power like regulating immigration. A law that is unnecessary or improper would theoretically not hold up in court. The same goes for executive action.
Perhaps the most infamous case of this was the Idaho manslaughter case against FBI sniper Lon Horiuchi for killing Vicki Weaver in the Ruby Ridge incident. His case was simply "removed" to federal court and dismissed under the supremacy clause (although this dismissal was later overturned narrowly when appealed).
This is why it's absolutely essential to always be aware of which types are value types in the .NET type system. Attempts by either users or the designers to conflate or unify them are ill-conceived. The nullability semantics could have been kept consistent if they went all the way back to the beginning of the CLR and did it that way, but this would have not been consistent with Java's JVM and type system (which they were trying to mimic).
That said, we already have value types like System.Int32 which inherit from System.ValueType (an abstract type) which inherits from System.Object (a non-abstract reference type), so things are already a bit weird.
For example in Eiffel by default they are references, but can also be turned into value types if the are blesses ones like numeric types, or if the developer tags them as expanded classes, either at definition or declaration type.
Delphi makes the distinction between classical object, and records from Object Pascal (both value based, and explicit pointers are required), or class types, heap only.
Modula-3 classes and records also follow similar approach, OBJECT follows the same semantic model of REF RECORDS.
For more modern examples, also D and Swift follow this approach.
And plenty of other examples for anyone wanting to dive into SIGPLAN.
It is in hindsight unfortunate that this idea didn't get into the CLR itself.
The blog post doesn't mention this, but whereas if I say my function only takes this 32-bit signed integer value type, a VB.NET caller can't hand it "null" because that's not a 32-bit signed integer - if instead I say it takes string (not the nullable string?) too bad, the VB.NET caller can just pass null anyway because in the CLR there's no distinction.
You're actually expected (if you provide public surface) to write a null test, in your C# code which explicitly says in the function signature that this mustn't be null, otherwise it might blow up at runtime because the CLR doesn't care.
Nullable types came into C# during the .NET Framework days, back when the team had very high bar to ever add features that would change the runtime as OS component.
Hence why async/await is such a mess of IL bytecode, as it was implemented in userspace so to say.
Only with .NET Core, they followed other languages in not tying the runtime to the OS, a lesson that Google also had to learn (ART is updatable via PlayStore since Android 12).
> That said, we already have value types like System.Int32 which inherit from System.ValueType (an abstract type) which inherits from System.Object (a non-abstract reference type), so things are already a bit weird.
But it all works, right? The runtime can do anything it wants to with the IL. The handling of Vector<T> is a good example of this - Locating arbitrary types/namespaces and emitting special instructions based upon the current machine's capabilities. Normalizing value vs reference semantics would be a tiny drop in this bucket.
I wonder if anybody has tried inheriting from System.ValueType or System.Object...I need to fire up an IDE and see what kind of virtuals and abstracts are exposed by doing so. If even possible.
It seems like an inheritance hierarchy build upon abstract classes that provide no usable interface just means "hey we need this inheritance for...reasons... cause its legacy!" on the one hand, and "we can rip all this useless ** out" on the other hand.
Truthfully I think the language lost something critically important when we went gung-ho on purging ourselves of the EVILS! of nullable types.
Back in the Paleolithic, the only way to get a nullable value type was to extremely explicitly box it into a Nullable<T>. The distinction between value and reference types was crystal clear and unmistakable. Boxing values required an active and deliberate decision.
Now I guess we just box everything because null checks are hard or something.
C# doesn't box value types and can be treated like an object semantically for things like generics.
IMO, we should just do away with nullability and use the optional/maybe approach as wrappers for potential values. Null shouldn't really exist ideally, especially in OO because it is a unit value and also the parent value for all objects. I appreciate nullability being introduced but it causes a fork in types by two branches at the top of the hierarchy in most cases and more conceptually just associates these optionals with this flawed concept.
Providing a platform for defamation and other tortious speech is generally legally protected under §230. They still have to respond to court orders and DMCA requests, though. This is how sites like Kiwi Farms remain online. That said, commercial apps can sometimes be sued under defective product laws.
Are there any POSIX or ISO guarantees on "FILE"? I think it's safe to assume that it isn't an incomplete type, but all functions that use it operate on pointers anyway. Storing a copy of a "FILE" object might result in each copy pointing to the same underlying file handle but having different internal state.
The amusing thing is that even today, there's a "blink" method on JavaScript strings. It's totally useless today, but it's still there for whatever reason. In fact, they don't even HTML escape the argument, so they were arguably terrible from the beginning.
Removing it will cause old code to throw an exception. By making it a no-op the code will remain working. There's tons of old unmaintained stuff on the web.
Windows actually created a new process type for this: Pico processes[1]. This allows WSL1 to perform quite a bit better than Cygwin on something like Windows XP.
In the USA, both are true. Civil servants can (and should) refuse to follow an order they think is unconstitutional, illegal, or simply unwise. But this won't stop them from being fired for insubordination. I don't think the courts will attempt to force the president to retain subordinates that are actively opposing him on the job.
If they can still be fired, then what does it even mean to say that they can refuse to follow an unconstitutional order? Refusal to follow any order is not illegal. If the consequences for refusing to follow an illegal order are the same as the consequences for refusing to follow a legal order, then there is no sense in saying civil servants can refuse illegal orders.
The consequences for following an illegal order include being sued, being held in contempt of court, or being criminally prosecuted by a subsequent administration. They don't have the same immunity that presidents do because they don't have a direct vesting of authority under Article II.
Ok? The question is, in what sense are they allowed to refuse an illegal order, given that the consequences are the same as refusing to follow a legal order?
