&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?

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.

systemd

Interesting. So they did it two years ago for the lols… i mean for the u8"😀"s*…which wasn’t even really needed as one of the PR comments pointed out.

* Yes, the mission creep is so bad the shit show that is systemd has emoticons.

I do think it would’ve been worth it to introduce ++ for general appending.

I already mentioned (val..).next() which is both safe* and explicit about it being a generic stepping operation instead of possibly being sugar for {x = x + 1; x}.

Also, calling it “appending” is weird for us folks coming from languages like C 😉

* you don’t have to worry about what i32::MAX++ would/should return.

Submit an issue asking for preemptive GNS (Gnu Name System) domain name support, and leave a link to it here.

Multi-threading support

Who stopped using pthreads/windows threads for this?

Unicode support

Those who care use icu anyway.

memccpy()

First of all, 😄.
Secondly, it’s a library feature, not a language one.
Thirdly, it existed forever in POSIX.
And lastly, good bait 😄.

whats so bad about Various syntax changes improve compatibility with C++

It’s bad because compiler implementations keep adding warnings and enabling them by default about completely valid usage that got “deprecated” or “removed” in “future versions of C” I will never use or give a fuck about. So my CI runs which all minimally have -Wall -Werror can fail with a compiler upgrade for absolutely irrelevant stuff to me. If it wasn’t for that, I wouldn’t even know about these changes’ existence, because I have zero interest in them.

Those who like C++ should use C++ anyway. They can use the C+classes style if they like (spoiler alert: they already do).

I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

Because C doesn’t exist in a vacuum, and Rust exists. Other choices exist too for those who don’t like Rust.

My C projects are mature and have been in production for a long time. They are mostly maintenance only, with new minor features added not so often, and only after careful consideration.

^{Still interested in knowing what relevant projects will be using C23.}

That’s good and all, but we all explicitly pass -std=gnu99 (or -std=c99 if you don’t care about MSYS2 compat) in our build scripts buddy 😉

Okay, maybe not all all. But you get the idea.

Are there any relevant projects who use the increasingly C+±infested newer versions of the language?

The general theme of your comment is good, but the example is…

The string “AAAAA” cannot be said to be greater or less than “AAAAB”

But in general the name “John” is not considered to be higher/lower than “Mark”

// rust
  eprintln!("{}", "AAAAB" > "AAAAA") // true
  eprintln!("{}", "Mark" > "John") // true

// C
  printf("%d\n", strcmp("AAAAB", "AAAAA")); // 1
  printf("%d\n", strcmp("Mark", "John")); // 1

strcmp() docs:

strcmp() returns an integer indicating the result of the comparison, as follows:

• 0, if the s1 and s2 are equal;

• a negative value if s1 is less than s2;

• a positive value if s1 is greater than s2.

So basically, if C had higher level constructs, it would be identical to Rust here.

So, even if it is cool to manipulate strings by using addition/subtraction, it is still bad language design and very unintuitive.

Rust has impl Add<&str> for String and impl AddAssign<&str> for String. Both append as expected.

But maybe you meant numeric addition specifically.

In that case, yes, Rust doesn’t have that, although it’s an impl<'a> Step for &'a str away from having something similar (it would be ("AAAAA"..).next()).

impl Step for char already exists of course, but shouldn’t if we take your argument to its logical conclusion.

Oh, and C would most definitely have this feature if it could. Numerical manipulation of chars is commonplace there.

Can’t think of anything.
The novelty must have worn off over time.
Or maybe my mind doesn’t get blown easily.

With hyper-threading and preemption in mind, maybe it’s concurrency all the way down 😎 . But we should definitely keep this on the down low. Don’t want the pesky masses getting a whiff of this.

Yeah. I read the linked explanation by OP.

User repositories is basically how FMS on Freenet (now Hyphanet) works. The big difference is that JSON is used at AT instead of XML 😁. Also, things on Freenet are “content addressable” (what a buzz word) and immutable, always has been.

General data scalability is a part of the Freenet network model. App bandwidth and sync is admittedly not optimal, since on FMS, you basically pull from everyone’s feed to your database (bar the ones you distrust, or others you trust their distrust judgment distrust). But that can be trivially fixed by adding watchers split over the keyspace. These watchers can give users metadata about who to pull/update from. This of course was never actually needed since the user-base is small.

So reading about AT, I was left wondering. Is this really innovative? Then I read this part

Our founding engineers were core IPFS and Dat engineers

… and everything made sense. The masters of pretending they are coming up with new stuff are at it again.

Some shallow observations without really getting into the code:

misc

• Was hosting labeler/ResNet50_nsfw_model.pth in the repository really necessary?
  (I like my --filter=tree:0 clones to be maximally fast and small.)
• Why not declare all dependencies in the workspace?
• How old is the code (for real)?

rsky-crypto

• anyhow in library code.
• Not liking that multibase dependency much either. I know that base64 at least got re-written since that crate’s last update (Nov 6, 2020).

rsky-feedgen

• serde_cbor is long dead (I was a user myself).
• I’m not even sure why serde_cbor and serde_ipld_dagcbor are dependencies anyway.
• We moved from lazy_static to once_cell a long time ago. And your use is available in std on stable Rust today.

rsky-firehose

• Here, all three CBOR dependencies are actually used.
• CBOR (the format) used in $CURRENT_YEAR is meh anyway. But I guess that comes from IPLD.

rsky-identity

• anyhow in library code.

rsky-pds

• That’s quite the dependency list! Too long for me to take a closer look.
• How many *base* dependencies does one need? All of them of course!

rsky-syntax

lazy_static and anyhow again.

That’s all from a code organization and ecosystem PoV. Otherwise, things look normal and not fancy (which is good).

Unfortunately, I don’t have the time to look beyond that at this moment.