BB_C

Use libcosmic 😑

No, but seriously.. skip to the end.

Iced and Egui both can’t handle Arabic, which is a deal breaker.

Iced can handle Arabic shaping-wise when cosmic-text is used, but it can't handle the direction (yet). If you only need it for the interface, a shit workaround would be to prefix all text with an RLM (RIGHT-TO-LEFT Mark). This would left-align all text of course.

Iced takes forever to compile and iterate, maybe that’ll be fixed with dynamic linking.

Fast iteration is already fixed by using cranelift in your release-dev profile (or whatever you want to call it), and mold as a linker. The binary will be slower, but iteration will be much much faster.

Okay, something helpful instead: Did you try asking in the rust:gnome.org matrix room mentioned in the project page?

&Bar is a reference to something. That something is either a part of self, or a part of the static context. There is no other context because there is no runtime/GC. So there is no logical not-nonsensical scenario where this would be both a valid and a limiting situation in Rust. And this is why your surface analogy to Index is invalid.

If the return value may depend on something other than self or the static context, and still need to be reference-like, then the trait definition is wrong. It should either return a Cow, or go for the obvious generalization of returning impl AsRef<Bar> values. With that generalization, references, Cows, and more can be returned.

There is also the possibility that the trait definition is right, and you (the implementer) are trying to break a (probably) deliberate constraint (e.g. the return value in Index being tied to &self).

I would wager a guess that what you call an escape hatchet is considered a very bad C# style anyway (or will/should be). Just like how mutable statics are considered very bad in Rust 😉

Cow does not work when you are actually required to return a reference

What does that even mean? Can you provide a practical example?

(I'm assuming you're familiar with Deref and autoref/autoderef behaviors in Rust.)

Is what the author calls a C# borrow checker purely lexically based? The first error message gives that impression. And if it is, then it wouldn't qualify for any such comparisons with 2018+ Rust.

1. Unconvincing use-case: why is returning an Option not an option?
2. Unconvincing objection: what concrete problems are caused by utilizing Cows?
3. Wrong demonstrated "solution": why would one have to create a value and leak it with each call instead of using one LazyLock static?

unrecoverable errors in the form of panic

ahem

Their indices start at 1

Why do you hate zsh so much? 🙂

Sorry, I thought you meant the use of .. in Rust is odd. So I pointed out that {0..9} and{a..z}is also used at least in bash and zsh. That's at least 10s of millions of users!

I know of .. being used for appending by lua at least. So still not odd-ball I would argue, since the people who interacted with lua code in their life probably outnumber those who interacted with all functional languages combined.

It’s not like it’s an odd-ball usage of the symbols, that’d be .. which I vaguely remember some language using.

I take it, you don't bash/zsh/...?

Is this going to be re-posted every month?

Anyway, I've come to know since then that the proposal was not a part of a damage control campaign, but rather a single person's attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn't, and there isn't.

The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical ~~mushrooms~~ guidelines and real specified and implemented profiles.

The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.

So not only there was no concrete strike back, it wasn't even the empire that did it.

Maybe this is a reductionist simplification of it, but his point is basically that, at least in the context of rust, async code is explicit and easy to introduce in a blocking context by simply blocking on it, while blocking code is not explicit about how blocky it is (and it's not a binary), and thus, it's not trivial to know where explicit unblocks are needed in an async context.

Blocking on async code is usually done with some_executor::block_on(), of which some very lightweight implementations exist, combined with the possibility of not requiring that the data's ownership be moved to the executor, nor is the data required to be Sendable to other threads (an executor doesn't have to be a multi-threaded work-stealing one).

Meanwhile, unblocking is done usually via blocking::unblock() or some_executor::spawn_blocking(), and doesn't offer such flexibility.

Someone should write "Leaky Abstraction" arguments considered harmful to finish the circle. Feel free to contact me for advice.

It's more pointless that harmful, but going with the latter is better branding.