unicode-proposals VS proposal-error-cause

Because... not wanting to have to deal with racism? News flash: There's no official ISO 3166 code for a confederate flag, regardless of IOS or Android. You're not typing one.

You mean the "Cool S", right? Well, the standard for encoding text (and emoji) on computers is Unicode - they have a list of selection factors for what make good emoji candidates. The Cool S, sadly, doesn't seem to fulfill the requirements, being an exact image (instead of a representation of a broad concept) and not having any sort of apparent use. It might fare better as a non-emoji symbol (like 🗫), those seem to have less strict requirements. In any case, I can't find any evidence that somebody's gone to the effort to write up a full proposal, just this somewhat half-hearted suggestion from 2018.

Source: https://github.com/Crissov/unicode-proposals/issues/256

Soviet flag emoji proposal

I see lots of misinformation following this about copyright and fonts. In the United States, fonts are copyright-able as programs but not as letterforms. You cannot copyright the basic elements of language, so anyone can make his own executable program (i.e. a font file) that has literally any glyph in it without infringing on copyright. Note that some things that we make think of as glyphs (e.g. the recycling sign or the textile care symbols) can be trademarks and protected under that class of intellectual property law.

There's more proposals here:

https://github.com/Crissov/unicode-proposals/issues/

There's a rather whimsical one proposed called the Priest Emoji!

https://github.com/Crissov/unicode-proposals/issues/425

Instead of having proposals, why not just implement every thing/subject/object we can think of?

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

Error Cause : .cause property on all Error types slides.

The impact and cause provides the most value when paired with the other, and that's what Error Cause enables and what Pony Cause is is a ponyfill for and provides helpers for.

Well, we have error-cause on stage-3 for the same and with which we could do something like:

Error Cause: Enhancing errors with a distinct "cause".

Error Cause