[fluffything]

> So? Use the external library then. One thing does not preclude the other.

That's what everybody already does? You are proposing to, instead of doing that, move that library into the standard library where it cannot ever change.

> You can provide standard Unicode handling that is good enough for 99% software out there.

That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because it doesn't deal with unicode at all.

You are suggesting moving something into standard that would make unicode software harder to update, and would make the standard library huge (>20mb larger) for all programs (the unicode tables take a lot of binary size), even those that don't use unicode, to try to solve a problem that does not exist.

> I work in such an organization and no, we cannot use third-party packages

If a Rust user cannot write `cargo add unicode-segmentation`, they have bigger problems than not being able to handle grapheme clusters. You can't run async code because you don't have an executor, you can't do http because the standard library doesn't support that, you can't solve partial differential equations, or do machine learning, or pretty much anything interesting with Rust.

That's bad for you, but the solution isn't to make Rust bad for everybody else instead.

If your organization doesn't let you use third-party packages, then write your own: that's what your organization wants you to do.

Some organizations want all code in CamelCase, they can't use the standard library at all. But the solution isn't to make Rust case insensitive, or to prove a 2nd standard library API for those organizations.

[jfkebwjsbx]

> That's already in std? 99% of the code doesn't need to handle unicode grapheme clusters, because it doesn't deal with unicode at all.

99% of the software does not use the entirety of the std. Something is good to be in the std if for that domain it solves the majority of problems, not if everyone uses it.

> You are suggesting moving something into standard that would make unicode software harder to update

It is equally hard to update.

When people say that std libraries are harder to update they refer to changes in interfaces, not incremental updates to tables etc.

> and would make the standard library huge (>20mb larger) for all programs (the unicode tables take a lot of binary size)

Including the tables in every executable even when not used is a broken implementation.

> If a Rust user cannot write `cargo add unicode-segmentation`, they have bigger problems than not being able to handle grapheme clusters.

It is not a "problem". In most commercial software, libraries and versions are vetted. Same applies for all languages. If something is in the std, then it is already in, that is why it is useful.

> That's bad for you, but the solution isn't to make Rust bad for everybody else instead.

I don't see why that makes Rust "bad". It sounds like the opposite to me!

> Some organizations want all code in CamelCase, they can't use the standard library at all.

You are going off-topic to support your point.

[fluffything]

> I don't see why that makes Rust "bad".

And this is why people suggesting what you are suggesting never manage to achieve the change.

> 99% of the software does not use the entirety of the std

Most Rust software uses most of it.

> You are suggesting moving something into standard that would make unicode software harder to update

How do you update the unicode tables for those stuck with Rust 1.0 ? If you are going to make this claims, back them up.

> It is not a "problem". In most commercial software, libraries and versions are vetted. Same applies for all languages. If something is in the std, then it is already in, that is why it is useful.

So your organization does support third-party packages, you are just to lazy to ask for vetting ? That's not what you claimed above (you claimed that your organization does not support third-party packages at all).

The answer to this is simple, ask your organization to vet this library. If that's too complicated and takes too much effort, improve your organization's process.

Suggesting that only because you are too lazy to vet a library that library should be in standard is a laughable proposal. Think about the trade-offs, evaluate them, weight them, and if you still think doing so is worth it, write an RFC. The process for putting things into standard is open.

But if your only argument is "me,me,me,me" that's not going to go anywhere.