Bear in mind that simultaneous interpretation by humans (eg with a headset at a meeting of an international organisation) has been a thing for decades.

MCP can use SSE to support notifications (since the protocol embeds a lot of state, you need to be able to tell the client that the state has changed), elicitation (the MCP server asking the user to provide some additional information to complete a tool call) and will likely use it to support long-running tool calls.

Many of these features have unfortunately been specified in the protocol before clear needs for them have been described in detail, and before other alternative approaches to solving the same problems were considered.

For the existence of any invocation of `::clone()` in the method body to be encoded in the method signature, we'd either need some wild new syntax, or the compiler would need to be able to encode hidden information into types beyond what is visible to the programmer, which would make it very hard to reason about its behavior.

The compiler doesn't introspect the code inside the method and add additional hidden information to its signature (and it would be difficult to reason about a compiler that did).

Strong disagree. Elegant software is easy to understand when read, without extraneous design elements, but can easily have greater or fewer lines of code than an inelegant solution.

No, this is backwards. We have to require all generic parameters are Clone, as we cannot assume that any are not used in a way that requires them to be Clone.

> The reason this is the way it is is probably because Rust's type system wasn't powerful enough for this to be implemented back in the pre-1.0 days. Or it was just a simple oversight that got stabilized.

The type system can't know whether you call `T::clone()` in a method somewhere.

Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it.

And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.

It’s mostly the same with PON now. I’ve always had success with the FS.com PON SFPs, once I get the necessary information for the connection to program them with (the difficulty of which can vary from “ask the tech installing the connection nicely” to “take apart the ISP-provided CPE and solder wires to the debug console pads”).

Given the popularity of the product you’re presumably aware this isn’t a typical experience. I certainly haven’t encountered disconnects or ANC switching off uncommanded, and the only time I get one-sided sound is if one side runs out of battery. You might consider asking Apple to replace them.