> <blank> phone number on <blank> IMEI/IMSI should be allowed to register presence on Jibe

Funny, I more or less said a few weeks ago that SIM cards do not guarantee freely being able to swap numbers between phones more than eSIMs do, because the carrier could tie the SIM's phone number to the IMEI in the backend either way. That was just kinda dismissed as a not being a real threat... and yet here it seems exactly what's happened for the RCS part of your service!

Exactly. People are very hung up on "unwrap" but even if it wasn't there at all, you will have devs just manually writing the match. Or, even more likely, using a trivial 'unwrap!" macro.

There's also an assumption here that if the unwrap wasn't there, the caller would have handled the error properly. But if this isn't part of some common library at CF, then chances are the caller is the same person who wrote the panicking function in the first place. So if a new error variant they introduced was returned they'd probably still abort the thread either by panicking at that point or breaking out of the thread's processing loop.

Yes but you also get to say "We're down? Yes of course we're down, 30% of the internet is down. Nothing we can do"

Like the old saying: Nobody Ever Got Fired for Buying IBM.

This feels better than the original anyway. I never liked the yellow color that one had. Maybe it was an artistic choice, but to me it just looked degraded, like when white plastic is left exposed to the sun.

Agreed. Seemed like a particularly poor choice to show off the capabilities of an image compression algorithm

Foveated rendering is already a thing. But since it needs to be coded for in the game, it's not really being used on PC games. Games designed for Playstation with the PS VR 2 in mind do use foveated rendering since they know their games are being played with hardware that provides eye tracking.

Just tested that in C# and it seems they made the smart decision to not allow shenanigans like that in a finally block:

CS0157 Control cannot leave the body of a finally clause

What about throwing an exception from the finally clause?

This loops, if that's what you're asking:

    while (true)
    {
        try
        {
            try { return; }
            finally { throw new Exception(); }
        }
        catch { }
    }

Yes that is the one exception (heh) to the rule unfortunately. You can throw from anywhere so it must support unwinding from any point. So if you were really intent on abusing the finally you could wrap the try-finally in a try-catch and then throw from the finally and put your continue in the catch.

The finally behave slightly different in CIL. You have protected regions and finally/fault/catch/filters handlers attached. So in order to support continue inside finally you should introduce some state machine , which is complication and generally against Roslyn design limitation.

ziml77's point is about the behaviour of the C# language. You seem to be talking about implementation concerns. They're not relevant.

There's no solution to lock-in because there must be some massively shared domain that the email address exists on for the anonymity of the service to properly work. However if you are simply looking for an alternative to Apple, Fastmail offers a masked email service too.

Most other commenters here are honestly making me feel crazy for thinking that asking to hop on a call seemed perfectly reasonable. I don't even like calls most of the time, but I do recognize that sometimes they are a better way to communicate than text and this seems like one of those times.

I wasn't too averse to using the construction until I saw the latest Eddy Burback video where he had an AI encouraging the delusions he was faking for the sake of the video. The sheer number of times the AI said "it's not just X, it's Y" absolutely broke any willingness I had to ever say anything like that again.

"Nope"? What is not factual about that statement?

It’s not what I said? Not even remotely.